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
