Kevin,
So, wouldn't it be better, if it's actually feasible to detect the problem situation, to make this another situation where SELECT FOR UPDATE can cause serialization failures? That would allow applications to count on getting the rows in the requested order if the query completes successfully. If existing documentation doesn't already cover the possibility of serialization failures when using FOR UPDATE, it should. If we need to document something around the issue of this thread, that seems like the place to do it.
That's not how SELECT FOR UPDATE works. SFU is pessimistic manual locking, which is supposed to *wait* for the rows to be exclusively available. The deadlock timeout you encountered is the correct behaviour, not "serialization failure", which is what happens at commit time when the engine realizes that concurrent transactions are not serializably recreateable.
--Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
