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 ProcWaitForSign
"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
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 po
; From: Tom 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/msg00
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
re
