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
Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, January 21, 2008 5:01 PM
To: pgsql-hackers@postgreSQL.org
Subject: [LIKELY_SPAM][HACKERS] Thoughts about bug #3883
Steven Flatt's report in this thread:
http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php
exposes two more-or-less
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
Steven Flatt's report in this thread:
http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php
exposes two more-or-less-independent flaws.
One problem is that we allow operations like TRUNCATE on tables that are
open in the current backend. This poses a risk of strange behavior,
such as
