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.0302180938340.21206-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
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


pgsql-admin by date:

Previous
From: "Nick Fankhauser"
Date:
Subject: Re: Unable to run pg_dump from crontab
Next
From: Felipenasc@aol.com
Date:
Subject: Re: data-time type