Re: Update on true serializable techniques in MVCC

From: Florian Pflug <fgp(dot)phlo(dot)org(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Update on true serializable techniques in MVCC
Date: 2009-12-17 13:20:22
Message-ID: 4B2A3016.9090708@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16.12.09 16:40 , Kevin Grittner wrote:
> Nicolas Barbier<nicolas(dot)barbier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-12-17 13:25:02 Re: Streaming replication and non-blocking I/O
Previous Message Heikki Linnakangas 2009-12-17 13:18:55 Re: Hot Standby and prepared transactions