On 16.12.09 16:40 , Kevin Grittner wrote:
Nicolas Barbier<nicolas.barb...@gmail.com> wrote:
I am not sure whether the serialization failures that it may cause
are dependent on the plan used.
They are.
But so are failures due to deadlocks even today, no? The processing
order of UPDATES which involve joins isn't any more well-defined that
the order of rows returned by a similarly complex select I think.
Actually, I think the whole SIREAD-lock idea can be seen as a kind of
2PL with opportunistic locking and deferred deadlock detection. Instead
of making readers and writers block each other, you let them proceed in
parallel, and check if that resulted in any mutual toe-stepping later.
The surprising part is that SIREAD locks and those inConflict,
outConflict flags actually provide enough information to detect possible
problems. Or at least this is the idea I got after skipping through the
thesis for an hour or so.
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
