Tom Lane <> wrote:

> Just for starters, a 40XXX error report will fail to provide the
> duplicated key's value.  This will be a functional regression,

Not if, as is normally the case, the transaction is retried from
the beginning on a serialization failure.  Either the code will
check for a duplicate (as in the case of the OP on this thread) and
they won't see the error, *or* the the transaction which created
the duplicate key will have committed before the start of the retry
and you will get the duplicate key error.

> I think an appropriate response to these complaints is to fix the
> documentation to point out that duplicate-key violations may also
> be worthy of retries.

> but I see no mention of the issue in chapter 13.)

I agree that's the best we can do for stable branches, and worth

It would be interesting to hear from others who have rely on 
serializable transactions in production environments about what 
makes sense to them.  This is probably the wrong list to find such 
people directly; but I seem to recall Josh Berkus has a lot of 
clients who do.  Josh?  Any opinion on this thread?

Kevin Grittner
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to