Обсуждение: delete commands fails silently to delete primary key

I have table in 8.1.4 which tracks users logged into db

CREATE TABLE "session"
(
  workplace character(16) NOT NULL,
  ipaddress character(20),
  logintime character(28),
  loggeduser character(10),
  CONSTRAINT session_pkey PRIMARY KEY (workplace)
);

Commands executed at logon in same transaction are:

delete from session where workplace=E'LIIVA' ;
insert into session (workplace,ipaddress,logintime,loggeduser) values (
E'LIIVA' , inet_client_addr()::CHAR(14),
current_timestamp::CHAR(28),CURRENT_USER)

Sometimes (during locking contention or during heavy load) those commands
cause error:

2008-11-22 11:24:26 EET INSERT 1 47433335ERROR:  duplicate key violates
unique constraint "session_pkey"
2008-11-22 11:24:26 EET INSERT 2 47433335STATEMENT:  delete from session
where workplace=E'LIIVA' ;insert into session
(workplace,ipaddress,logintime,loggeduser) values (  E'LIIVA' ,
inet_client_addr()::CHAR(14), current_timestamp::CHAR(28),CURRENT_USER)

No other client can add 'LIIVA' primary key.
Any idea why this error occurs and how to fix ?

Andrus.

"Andrus" <kobruleht2@hot.ee> writes:
> I have table in 8.1.4 which tracks users logged into db

There have been a number of index-corruption bugs fixed since 8.1.4 ...

In particular, if it's possible that any of these clients abort before
committing these insertions, the vacuum race condition bug fixed in
8.1.10 is a pretty likely candidate for your problem.

            regards, tom lane

> There have been a number of index-corruption bugs fixed since 8.1.4 ...
>
> In particular, if it's possible that any of these clients abort before
> committing these insertions, the vacuum race condition bug fixed in
> 8.1.10 is a pretty likely candidate for your problem.

I changed second statement to

INSERT INTO session ('MYCOMPNAME',ipaddress,logintime,loggeduser)
   SELECT 'MYCOMPNAME',
inet_client_addr()::CHAR(14),current_timestamp::CHAR(28),CURRENT_USER
         WHERE NOT EXISTS (SELECT 1 FROM session WHERE
workplace='MYCOMPNAME')

where MYCOMPNAME is logging-in computer name.

Will this fix the isse or is it better to wait 100 ms  and re-try insert?

Andrus.

"Andrus" <kobruleht2@hot.ee> writes:
>> There have been a number of index-corruption bugs fixed since 8.1.4 ...
>>
>> In particular, if it's possible that any of these clients abort before
>> committing these insertions, the vacuum race condition bug fixed in
>> 8.1.10 is a pretty likely candidate for your problem.

> I changed second statement to ...
> Will this fix the isse

No.  Look, as you've been told several times already you are running a
very old version with a lot of known bugs.  Just update to the latest
in that branch.  It's not hard.

            regards, tom lane