Skip site navigation (1) Skip section navigation (2)

Re: User-facing aspects of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-05-28 01:07:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hmm, what I gathered was that that's not changing any basic semantic
> guarantees (and therefore is okay to control as a GUC).  But I
> haven't read the paper so maybe I'm missing something.
The paper never suggests attempting these techniques without a
predicate locking implementation.  It was just something Robert Haas
noticed during our discussion at the bar (and he wasn't even consuming
any alcohol that night!) that it would be a possible development path.
I don't think either of us sees it as a useful end point.
Basically, if you just took out locks on the rows you happened to read
(rather than doing proper predicate locking) you would still prevent
some anomalies, in a more-or-less predictable and controllable way.  I
think we both felt that the predicate locking might be the hardest
part to implement in PostgreSQL, so having such a proof of concept
partial implemenation without first implementing predicate locking
might fit with the "series of smaller patches" approach generally
preferred by the PostgreSQL developers.

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2009-05-28 01:08:00
Subject: Re: User-facing aspects of serializable transactions
Previous:From: Josh BerkusDate: 2009-05-28 01:01:16
Subject: Re: search_path vs extensions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group