Message-ID: <DEBD62702A904D449EA61A093D93E094@Demolish2>
From: "Donald Fraser" <postgres@kiwi-fraser.net>
To: "[ADMIN]" <pgsql-admin@postgresql.org>
References: <AANLkTindCeLyRmRbgV4ICxEBGRLwyBbm5yO2oLBHUnSc@mail.gmail.com>
	<4652.1273674753@sss.pgh.pa.us>
	<AANLkTilzcY_VGBiYdTJ2bomtECxJxipSyW4AcpLMsO76@mail.gmail.com>
	<22516.1273684573@sss.pgh.pa.us>
Subject: Re: Shutdown fails with both 'fast' and 'immediate' 
Date: Wed, 12 May 2010 21:03:44 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit


----- Original Message ----- 
Subject: Re: [ADMIN] Shutdown fails with both 'fast' and 'immediate'


> David Schnur <dnschnur@gmail.com> writes:
>> I'm less concerned with the particular query than with the general 
>> question
>> of when a shutdown could hang like this.  I expected this to be possible
>> when using -m fast, but my understanding was that -m immediate really 
>> forced
>> termination.
>
> Yeah, it's supposed to.  The sequence is pg_ctl -m immediate sends
> SIGQUIT to the postmaster, which in turn sends SIGQUIT to all its child
> processes, and their SIGQUIT interrupt handlers just immediately exit().
> I was thinking earlier that there might be a bug in the postmaster state
> machine that prevented it from sending SIGQUIT if it had already
> received SIGTERM (-m fast), but a look at the sources doesn't support
> that theory.  The only obvious theory at this point is that the backend
> is stuck in some uninterruptable kernel call, but it's hard to imagine
> what.
>
> Is the postmaster still there after -m immediate, or does it quit?
> If it's still there, maybe there's some problem in the earlier part
> of the sequence.
>
> A gdb stack trace from whichever processes are still there after -m
> immediate could be informative.  Another thing you could try is a
> manual "kill -QUIT pid" on the uncooperative backend(s).
>
> regards, tom lane

Just to add some more comments on similar observations.
We have a restore script that restores a database from a backup (pg_dump). 
The only users connected during the restore are postgres on localhost. In 
the script we use
pg_ctl stop -D $PGDATA -m immediate
to stop the database and have noted that this doesn't always work.
We recently upgraded from 8.1 to 8.3 and have never previously noticed this 
issue.
The main difference in our configuration between 8.1 and 8.3 is that we now 
have "autovacuum = on".
So for what its worth, the DELETE might be a "red herring".
Given our circumstance, I would be more inclined to think the issue is 
something to do with autovacuum as there are no DELETE statements in our 
restore procedure and we don't execute pg_ctl stop untill all statements are 
complete.

Regards
Donald Fraser