Re: Select For Update and Left Outer Join

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Patrick Earl" <patearl(at)patearl(dot)net>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Select For Update and Left Outer Join
Date: 2011-07-11 15:44:17
Message-ID: 4E1AD401020000250003F19D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 11.07.2011 05:45, Patrick Earl wrote:
>> The ability to lock on outer joins is quite useful. I've even
>> been contacted to ask if I was aware of any progress in this
>> area.
>
> 9.1 has a truly serializable isolation level, so I would suggest
> using that instead of SELECT FOR UPDATE.

Heikki beat me to the big point, but I'll elaborate a bit.

First, 9.1 is in beta testing, and will probably be released this
summer

Next, when using this feature be sure to use transactional
annotations and set things up so that a transaction which fails with
SQLSTATE 40001 is retried from the start. If you use serializable
transactions consistently, you can drop all FOR UPDATE and FOR SHARE
clauses, and most likely all explicit locks. (In our in-house
testing I've so far found one place where we needed to take an
explicit lock on a dummy table we created just to control access to
a sequence -- sequences don't follow normal transactional
semantics.)

Third, review this section, and consider the performance tips there:

http://developer.postgresql.org/pgdocs/postgres/transaction-iso.html#XACT-SERIALIZABLE

I'd be interested in hearing how it goes.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-07-11 15:48:22 Re: Full GUID support
Previous Message Peter Eisentraut 2011-07-11 15:44:04 Re: per-column generic option