Andres Freund <and...@2ndquadrant.com> writes:
> That's much better, yes. Two things:
> * I'd change the warning about unique key violations into a more general
> one about constraints. Foreign key and exclusion constraint are also
> affected...
I'll see what I can do.
> * I wonder if we should make the possible origins a bit more
> general as it's perfectly possible to trigger the problem without
> foreign keys. Maybe: "can arise when a table row that has been updated
> is row locked; that can e.g. happen when foreign keys are used."
IIUC, this case only occurs when using the new-in-9.3 types of
nonexclusive row locks. I'm willing to bet that the number of
applications using those is negligible; so I think it's all right to not
mention that case explicitly, as long as the wording doesn't say that
foreign keys are the *only* cause (which I didn't).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
