Re: persistent portals/cursors (between transactions)

> > But can't cursors not only be updateable inside transactions and
> > read-only outside transactions, as a work-around, which would bring
> > PostgreSQL at least a little closer to the standard?
> >
> > And in the long term, can't the lock that is acquired with FOR UPDATE be
> > released when the cursor is closed and not when the transaction is
> > finished?
>
> The way it has to be is that you say
>
> UPDATE ... WHERE CURRENT OF <cursor>
>
> My idea is to hold the CTID, retrieved via a junk attribute,
> of the last FETCH'ed row (of the table the locks are for)
> inside of the cursor information, and basically rewrite the
> WHERE CURRENT OF into a WHERE ctid = ... during parse.
>
> As long as we cannot safely hold such locks across Xact
> boundaries and guarantee that rows locked that way don't get
> moved by vacuum, I'd vote for making cursors that are FOR
> UPDATE inaccessable at Xact end.
>
> Reminds me that Al Dev is right. The law's of physics apply
> to software! Proof: vacuum sucks!

I am not sure that is true anymore of non-FULL vacuum. I thought it
didn't move tids, though it will remove expired ones. Tom?

Wonder if we should think of some kind of anti-FULL vacuum lock that can
be held during transactions with FOR UPDATE.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026