Re: persistent portals/cursors (between transactions)

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore.

> Really ? VACUUM FULL conflicts with AccessShareLock from the
> first.

I was speaking of lazy VACUUM, of course.

> If new vacuum does wrong thing with persistent read-only cursors
> it would do the wrong thing with the current cursors as well.

No, because current cursors don't span transactions.

> Of cource as Vadim mentioned before, HeapTupleSatisfiesVacuum()
> should take the transaction id in which the cursor was opened into
> account.

I haven't read all of that thread yet; maybe Vadim already had the idea
I just had of playing games with oldest-XMIN.

            regards, tom lane