Re: DISCARD ALL failing to acquire locks on pg_listen - Mailing list pgsql-hackers

From Tom Lane
Subject Re: DISCARD ALL failing to acquire locks on pg_listen
Date
Msg-id 14438.1234463651@sss.pgh.pa.us
Whole thread Raw
In response to Re: DISCARD ALL failing to acquire locks on pg_listen  (Matteo Beccati <php@beccati.com>)
Responses Re: DISCARD ALL failing to acquire locks on pg_listen
List pgsql-hackers
Matteo Beccati <php@beccati.com> writes:
>> Seems like we could/should fix UNLISTEN * to not do anything if it is
>> known that the current backend never did any LISTENs.

> Here's my proposed patch, both for HEAD and 8.3:

This seems a bit overcomplicated.  I had in mind something like this...

Index: src/backend/commands/async.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/commands/async.c,v
retrieving revision 1.145
diff -c -r1.145 async.c
*** src/backend/commands/async.c    1 Jan 2009 17:23:37 -0000    1.145
--- src/backend/commands/async.c    12 Feb 2009 18:28:43 -0000
***************
*** 277,282 ****
--- 277,286 ----     if (Trace_notify)         elog(DEBUG1, "Async_Unlisten(%s,%d)", relname, MyProcPid); 
+     /* If we couldn't possibly be listening, no need to queue anything */
+     if (pendingActions == NIL && !unlistenExitRegistered)
+         return;
+      queue_listen(LISTEN_UNLISTEN, relname); } 
***************
*** 291,296 ****
--- 295,304 ----     if (Trace_notify)         elog(DEBUG1, "Async_UnlistenAll(%d)", MyProcPid); 
+     /* If we couldn't possibly be listening, no need to queue anything */
+     if (pendingActions == NIL && !unlistenExitRegistered)
+         return;
+      queue_listen(LISTEN_UNLISTEN_ALL, ""); } 


        regards, tom lane


pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: GIN fast insert
Next
From: Tom Lane
Date:
Subject: Re: pg_migrator and handling dropped columns