Re: DISCARD ALL failing to acquire locks on pg_listen

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: DISCARD ALL failing to acquire locks on pg_listen
Дата
Msg-id 14438.1234463651@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: DISCARD ALL failing to acquire locks on pg_listen  (Matteo Beccati <php@beccati.com>)
Ответы Re: DISCARD ALL failing to acquire locks on pg_listen
Список 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 по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: GIN fast insert
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_migrator and handling dropped columns