> Good question. Does anyone have anything against changing this?
>
> -Peter
>
> On Thu 31 Aug 2006 10:11, Santiago Balaguer GarcÃa wrote:
> > Thanks James, I don't figure out to use primary key solves the problem
of
> > duplicate keys.
> > I had in radacct as primary key <<radacctid>> but now I am going to
have
> > <<acctuniqueid>>.
> >
> > This proble cause a new thread: why radacctid is the primary key of
radacct
> > table instead od acctuniqueid?
I used a slightly different solution in my PostgreSQL implementation :
ALTER TABLE ONLY radacct
ADD CONSTRAINT radacct_unique_session UNIQUE (
username, nasipaddress, nasportid, acctsessionid
);
NOTE: When duplicate records come in you will see errors in the
log file like these :
Fri Jul 7 13:06:47 2006 : Error: rlm_sql (sql): failed after re-connect
Fri Jul 7 13:06:47 2006 : Error: rlm_sql (sql): Couldn't insert SQL
accounting START record - ERROR: duplicate key violates unique
constraint "radacct_unique_session"
These errors are mostly informational, because when the insert
fails, rlm_sql will use the alternate "update" method and will
succeed.
This is the same method I used on a customized Cistron
server I used for over 5 years and had no problems.
For some reason acctuniqueid was not unique in the duplicate
packets, so my initial attempts at using it were unsuccessful.
PostgreSQL can have a primary key that spans multiple
columns, and would look like this {IIRC} :
ALTER TABLE ONLY radacct
ADD CONSTRAINT radacct_pkey_session PRIMARY KEY (
username, nasipaddress, nasportid, acctsessionid
);
I did not use this, because I did not want to significantly change
the default configuration of most of the tables. Once I get a chance
to clean up the admin interface I have been developing I will
likely want to add some changes to the PostgreSQL default schema
that will allow better management without affecting the default
configuration, but since I am not finished I don't want to add
the changes to CVS quite yet.