Re: persistent portals/cursors (between transactions)

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.
We'd need to invent Yet Another lock type that would prevent VACUUM.
Clearly that's perfectly doable.

But: having just finished a lot of work to ensure that VACUUM could run
in parallel with all "normal" database operations, I'm not that thrilled
at the prospect of introducing a new mechanism that will block VACUUM.
Especially not one that's *designed* to hold its lock for a long period
of time. This will just get us right back into all the operational
problems that lazy VACUUM was intended to get around. For example, this
one: if transaction A has an insensitive-cursor lock on table T, and a
VACUUM comes along to vacuum T and blocks waiting for the lock, then
when subsequent transaction B wants to create an insensitive cursor on T
it's going to be forced to queue up behind the VACUUM.

While temp tables may seem like an ugly, low-tech way to support
insensitive cursors, I think they may have more merit than you realize.

regards, tom lane