| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | simon | 2004-12-21 09:38:01 | Re: Re: RC2 and open issues |
| Previous Message | Tom Lane | 2004-12-21 06:57:17 | Re: Locale question |