Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
The simplest fix seems to be to invent an additional flag variable
signalAwaited which is set/cleared by ProcWaitForSignal and checked by
LockWaitCancel. This would make cancelling out of a ProcWaitForSignal call
Tom Lane [EMAIL PROTECTED] writes:
The simplest fix seems to be to invent an additional flag variable
signalAwaited which is set/cleared by ProcWaitForSignal and checked by
LockWaitCancel. This would make cancelling out of a ProcWaitForSignal call
exactly analogous to cancelling out of a
I wrote:
The issue Steven directly complained of is a potential for undetected
deadlock via LockBufferForCleanup. Ordinarily, buffer-level locks don't
pose a deadlock risk because we don't hold one while trying to acquire
another (except in UPDATE, which uses an ordering rule to avoid the
Tom Lane wrote:
What I propose we do about this is put the same check into TRUNCATE,
CLUSTER, and REINDEX that is already in ALTER TABLE, namely that we
reject the command if the current transaction is already holding
the table open.
+1.
The issue Steven directly complained of is a
