From: | Laurette Cisneros <laurette(at)nextbus(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Ed L(dot)" <pggeneral(at)bluepolka(dot)net>, <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: server won't shutdown |
Date: | 2003-02-18 17:39:56 |
Message-ID: | Pine.LNX.4.44.0302180938340.21206-100000@visor.corp.nextbus.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
I'm compiling in the patch now and will test as soon as I can.
I have to say, I have never received such fast responses and fixes with any
"support" for any other product.
Pg is the best!
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
From | Date | Subject | |
---|---|---|---|
Next Message | Felipenasc | 2003-02-18 17:41:26 | Re: data-time type |
Previous Message | Nick Fankhauser | 2003-02-18 17:29:22 | Re: Unable to run pg_dump from crontab |