On Wed, May 12, 2010 at 10:36 PM, Alvaro Herrera <alvhe...@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 <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
