----- Original Message -----
Subject: Re: Shutdown fails with both 'fast' and 'immediate'
David Schnur <dnschnur@xxxxxxxxx> 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
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
