Tom Lane wrote:
"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
Tom Lane <t...@sss.pgh.pa.us> wrote:
A re-sort after locking doesn't really make things all nice and
intuitive either.
Would it make any sense to roll back and generate a
SERIALIZATION_FAILURE?
If that's what you want then you run the transaction in serializable
mode. The point of doing it in READ COMMITTED mode is that you don't
want such a failure.
Well, you can get deadlocks in read committed mode, so it is not like
this mode is totally free of concurrency related failure possibilities.
Both serialization errors and deadlocks assume a write operation though.
But could we detect this case at all? That is, when we are re-reading
the updated tuple, do we remember that we did some sorting earlier?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
