| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
| Cc: | "John Bartlett" <johnb(at)fast(dot)fujitsu(dot)com(dot)au>, "FAST PostgreSQL" <fastpgs(at)fast(dot)fujitsu(dot)com(dot)au>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Updateable cursors |
| Date: | 2007-01-24 15:02:15 |
| Message-ID: | 1169650935.3772.16.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 2007-01-24 at 14:27 +0100, Zeugswetter Andreas ADI SD wrote:
> > That is also the safe thing to do, since PostgreSQL's implementation
> of
> > WITH HOLD cursors doesn't leave the rows locked. That can lead to the
> > rows being deleted from under the cursor, for which the standard is
> > unclear as to whether that is acceptable, or not.
>
> Um, the default use case is to "intent exclusive" lock the current row,
> so you can do some calculations on columns inside the application
> without
> them changing in the meantime.
> So, imho that lock is a substantial feature of FOR UPDATE cursors.
> The lock is usually freed as soon as you fetch the next row.
> In MVCC db's it is also a method to read a guaranteed up to date
> version.
Completely agree.
The standard doesn't say it, but it might be taken to imply that locks
continue to be held, as with 2PC, and released when the cursor is
closed. But I'm not really sure I'd want that either, IMHO.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Theo Schlossnagle | 2007-01-24 15:17:00 | Re: About PostgreSQL certification |
| Previous Message | Merlin Moncure | 2007-01-24 14:59:33 | Re: Default permissisons from schemas |