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

Re: Shared row locking

From: "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at>
To: <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)dcc(dot)uchile(dot)cl>,"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>,"Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>,"Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Shared row locking
Date: 2004-12-21 09:22:59
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA40184D27C@m0114.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
> In general, I agree with Tom: I haven't seen many programs that use
> extended SELECT FOR UPDATE logic. However, the ones I have seen have
> been batch style programs written using a whole-table cursor - these
> latter ones have been designed for the cursor stability approach.

I think if we add shared locks we should by default behave like 
cursor stability isolation level, that only holds one shared lock for 
the current cursor row. The semantics are well defined in SQL.
If you want repeatable read you need to change isolation level.
I know FK checks will need to keep the locks, but I would special case 
that.

Andreas

pgsql-hackers by date

Next:From: simonDate: 2004-12-21 09:38:01
Subject: Re: Re: RC2 and open issues
Previous:From: Tom LaneDate: 2004-12-21 06:57:17
Subject: Re: Locale question

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