Re: persistent portals/cursors (between transactions)

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Tom Lane wrote:
> >> If it's not holding any locks, I can guarantee you it's not
> insensitive.
> >> Consider VACUUM, or even DROP TABLE.
>
> > It's already possible to keep a lock accross transactions.
> > So it would keep an AccessShareLock across transactions.
>
> AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore.

Really ? VACUUM FULL conflicts with AccessShareLock from the
first. If new vacuum does wrong thing with persistent read-only cursors
it would do the wrong thing with the current cursors as well.
Of cource as Vadim mentioned before, HeapTupleSatisfiesVacuum()
should take the transaction id in which the cursor was opened into
account.

regards,
Hiroshi Inoue