| From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "John Bartlett" <johnb(at)fast(dot)fujitsu(dot)com(dot)au> |
| Cc: | "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 13:27:53 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901B7C98F@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kenneth Marshall | 2007-01-24 13:40:31 | Re: [GENERAL] Autovacuum Improvements |
| Previous Message | Pavan Deolasee | 2007-01-24 13:09:48 | Re: Free space management within heap page |