Re: Shared row locking - Mailing list pgsql-hackers

From Zeugswetter Andreas DAZ SD
Subject Re: Shared row locking
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D27C@m0114.s-mxs.net
Whole thread Raw
In response to Shared row locking  (Alvaro Herrera <alvherre@dcc.uchile.cl>)
List 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:

Previous
From: Tom Lane
Date:
Subject: Re: Locale question
Next
From:
Date:
Subject: Re: Re: RC2 and open issues