Tom Lane wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Tom Lane <tgl@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?
