Re: server won't shutdown - Mailing list pgsql-admin
From | Tom Lane |
---|---|
Subject | Re: server won't shutdown |
Date | |
Msg-id | 20307.1045537577@sss.pgh.pa.us Whole thread Raw |
In response to | Re: server won't shutdown (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: server won't shutdown
Re: server won't shutdown Re: server won't shutdown Re: server won't shutdown Re: server won't shutdown |
List | pgsql-admin |
I said: > Oh, duh! You don't need to be using NOTIFY explicitly --- you just have > to sit idle long enough to make the SI buffer overflow, and the system > will try to NOTIFY your backend anyway to make it read the SI message > buffer. Which is the path I was looking at --- that will leave > ImmediateInterruptOK false, preventing response to SIGTERM if the client > still hasn't done anything by the time it comes. > Patch forthcoming. Attached is the fix against 7.3 (or CVS tip). The same bug exists in 7.2 and 7.1, and should be fixable by the same patch (possibly with some fuzz). You can demonstrate the problem by doing 'LISTEN foo' in one psql and then 'NOTIFY foo' in another, then attempting a fast shutdown --- the first psql's backend will ignore you until the psql session does something. The same path can be followed without LISTEN if the first psql is simply left idle while the second one does a bunch of catalog-updating work (a few cycles of VACUUM ANALYZE usually suffice). Sigh, another day another bug... regards, tom lane *** src/backend/commands/async.c.orig Sun Sep 15 21:24:41 2002 --- src/backend/commands/async.c Mon Feb 17 21:38:47 2003 *************** *** 599,604 **** --- 599,614 ---- if (notifyInterruptEnabled) { + bool save_ImmediateInterruptOK = ImmediateInterruptOK; + + /* + * We may be called while ImmediateInterruptOK is true; turn it off + * while messing with the NOTIFY state. (We would have to save + * and restore it anyway, because PGSemaphore operations inside + * ProcessIncomingNotify() might reset it.) + */ + ImmediateInterruptOK = false; + /* * I'm not sure whether some flavors of Unix might allow another * SIGUSR2 occurrence to recursively interrupt this routine. To *************** *** 626,631 **** --- 636,648 ---- elog(LOG, "Async_NotifyHandler: done"); } } + + /* + * Restore ImmediateInterruptOK, and check for interrupts if needed. + */ + ImmediateInterruptOK = save_ImmediateInterruptOK; + if (save_ImmediateInterruptOK) + CHECK_FOR_INTERRUPTS(); } else {
pgsql-admin by date: