Abort state on duplicated PKey in transactions

From: Haroldo Stenger <hstenger(at)adinet(dot)com(dot)uy>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Abort state on duplicated PKey in transactions
Date: 2001-09-08 17:20:28
Message-ID: 3B9A535C.D3CC7F65@adinet.com.uy
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi dear people,

Now I'm reposting this on hackers from general, sorry if no fully
suitable.

We are building a RAD tool (GeneXus) support, for PostgreSQL, as I have
mentioned before a number of times.

A problem which arose, is that within a transaction, if one inserts on a
table and the PK restriction is violated, the transaction aborts and
leaves itself in abort state. One has to END the transaction and start
a new one. This is a problem, in large transactions, where lots of
things have been done to the database, and an insertion is to be done,
which may yield an error just because the PK already existed. The whole
transaction should have to be redone if the insertion failed. A
solution, could be to query for the existance of the PK, just before the
insertion. But there is a little span between the test and the
insertion, where another insertion from another transaction could void
the existance test. Any clever ideas on how to solve this? Using
triggers maybe? Other solutions?

I'm aware that savepoints and nested transactions will be implemented in
future versions, but how to solve the problem before that starts
working?

Thanks

Regards,
Haroldo.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haroldo Stenger 2001-09-08 19:22:32 Re: Abort state on duplicated PKey in transactions
Previous Message Matthew T. O'Connor 2001-09-08 16:21:58 Re: Abort state on duplicated PKey in transactions