Re: Stefan's bug (was: max_standby_delay considered harmful)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, Simon Riggs <simon@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, Andres Freund <andres@anarazel.de>, Florian Pflug <fgp@phlo.org>, Dimitri Fontaine <dfontaine@hi-media.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>, Bruce Momjian <bruce@momjian.us>, Greg Smith <greg@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>
Date: 2010-05-13T02:41:53Z
Lists: pgsql-hackers
On Wed, May 12, 2010 at 10:36 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > Excerpts from Robert Haas's message of mié may 12 20:48:41 -0400 2010: >> On Wed, May 12, 2010 at 3:55 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> > I am wondering if we are not correctly handling the case where we get >> > a shutdown request while we are still in the PM_STARTUP state. It >> > looks like we might go ahead and switch to PM_RECOVERY and then >> > PM_RECOVERY_CONSISTENT without noticing the shutdown. There is some >> > logic to handle the shutdown when the startup process exits, but if >> > the startup process never exits it looks like we might get stuck. >> >> I can reproduce the behavior Stefan is seeing consistently using the >> attached patch. >> >> W1: postgres -D ~/pgslave >> W2: pg_ctl -D ~/pgslave stop > > If there's anything to learn from this patch, is that sleep is > uninterruptible on some platforms. This is why sleeps elsewhere are > broken down in loops, sleeping in small increments and checking > interrupts each time. Maybe some of the sleeps in the new HS code need > to be handled this way? I don't think the problem is that the sleep is uninterruptible. I think the problem is that a smart shutdown request received while in the PM_STARTUP state does not acted upon until we enter the PM_RUN state. That is, there's a race condition between the SIGUSR1 that the startup process sends to the postmaster to signal that recovery has begun and the SIGTERM being sent by pg_ctl. However, since I haven't succeeded in producing a fix yet, take that with a grain of salt... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company