Hiroshi Inoue <Inoue@tpf.co.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