Simon Riggs wrote:
On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote:
On Wed, May 12, 2010 at 7:26 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
On Wed, 2010-05-12 at 07:10 -0400, Robert Haas wrote:
I'm not sure what to make of this. Sometimes not shutting down
doesn't sound like a feature to me.
It acts exactly the same in recovery as in normal running. It is not a
special feature of recovery at all, bug or otherwise.
Simon, that doesn't make any sense. We are talking about a backend
getting stuck forever on an exclusive lock that is held by the startup
process and which will never be released (for example, because the
master has shut down and no more WAL can be obtained for replay). The
startup process does not hold locks in normal operation.
When I test it, startup process holding a lock does not prevent shutdown
of a standby.
I'd be happy to see your test case showing a bug exists and that the
behaviour differs from normal running.
In my testing the postmaster simply does not shut down even with no
clients connected any more once in a while - most of the time it works
just fine but in like 1 out of 10 cases it get's stuck - my testcase (as
detailed in the related thread) is simply doing an interval load on the
master (pgbench -T 120 && sleep 30 && pgbench -T 120 - rinse and repeat
as needed) and pgbench -S && pg_ctl restart && pgbench -S in a lop on
the standby. once in a while the standby will simply not shut down
(forever - not only by eceeding the default timeout of pgctl which seems
to get triggered much more often on the standby than on the master -
have not looked into that yet in detail)
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
