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

Re: incoherent view of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Emmanuel Cecchet" <manu(at)frogthinker(dot)org>,<pgsql-hackers(at)postgresql(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: incoherent view of serializable transactions
Date: 2008-12-23 16:10:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>>> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> 12/23/08
9:47 AM >>> 
> Kevin Grittner wrote:
>>>>> Emmanuel Cecchet <manu(at)frogthinker(dot)org> 12/23/08 8:59 AM >>> 
>>> Why don't users program the application to
>>> deal with a lower isolation (actually I think they do)?
>> There really are good reasons.  I'm not up to going through that
>> but if there is genuine interest in the topic perhaps I can follow
>> later.
> Well, the reason why people rely on isolation provided by database in

> general is to make it easier to develop applications. One less thing
> worry about. That's why people use RDBMS, transactions, etc. to begin
This is the heart of it.  The argument is getting made that you don't
need serializable transactions because you can duplicate the
concurrency control with a combination of read_committed transactions
and explicit lock requests.  I could also duplicate the functionality
of a DBMS with a bunch of disk files and custom, hard-coded access
logic, but I sure wouldn't want to do so.
> If you have a concrete suggestion (= patch) for the documentation,
> all ears.
Well, I figured I should try to get a consensus here before submitting
a patch.  Last time I tried submitting a simple patch to remove the
line about the PostgreSQL community not knowing about any other
databases which use predicate locking, I got shot down hard.
Does the phantom receipt example from the original post seem like a
reasonable thing to include in the doc patch?  Does someone have a
more comprehensive summary of where the issues are than I've been able
to generate so far?
The patch should also include information on workarounds.  I'd be
inclined to frame them in terms of how to duplicate the behavior of
serializable transactions on other databases from which the reader
might be converting, which would start with using SELECT FOR SHARE for
any SELECT within a serializable transaction.  That doesn't cover
everything, because, unlike Sybase, et al, it doesn't block
conflicting INSERTs.  I'm not sure I have a firm conceptual grasp on
when and how that renders the SELECT FOR SHARE technique incomplete,
but I could try to think it through.  If someone already has
comprehensive guidelines on that, it would save time and might improve
the quality of the docs.

In response to


pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-12-23 16:12:09
Subject: Re: incoherent view of serializable transactions
Previous:From: Heikki LinnakangasDate: 2008-12-23 15:47:37
Subject: Re: incoherent view of serializable transactions

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