Re: server won't shutdown - Mailing list pgsql-admin
From | Laurette Cisneros |
---|---|
Subject | Re: server won't shutdown |
Date | |
Msg-id | Pine.LNX.4.44.0302220841280.1523-100000@visor.corp.nextbus.com Whole thread Raw |
In response to | Re: server won't shutdown (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-admin |
Ok, I let the server run for a few days (usually long enough to get into this situation) and then did a shutdown. No hang. Could be fixed. Thanks! L. On Mon, 17 Feb 2003, Tom Lane wrote: > 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 > { > -- Laurette Cisneros, L.D. The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com ---------------------------------- "No man is wise enough by himself" -- Titus Maccius Plautus (254 Bc - 184 BC), Miles Gloriosus
pgsql-admin by date: