max_standby_delay considered harmful
in [PgSql]
|
Prev: Further Hot Standby documentation required
Next: [HACKERS] Streaming replication - unable to stop the standby
From: Simon Riggs on 12 May 2010 07:26 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. You may think its a strange feature generally and I would agree. I would welcome you changing that in 9.1+, as long as your change works in both recovery and normal running. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Greg Stark on 12 May 2010 07:33 On Wed, May 12, 2010 at 12:26 PM, Simon Riggs <simon(a)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. I admit I've sometimes been surprised that smart shutdown was waiting when I didn't expect it to. It would be good to give the shutdown more feedback. If it explicitly shows "Waiting for n sessions with active transactions to commit" or "Waiting for n sessions to disconnect" then the user would at least understand why it was waiting and what would be necessary to get it to continue. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 12 May 2010 08:52 On Wed, May 12, 2010 at 7:26 AM, Simon Riggs <simon(a)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. There are other things we might want to change about the shutdown behavior (for example, switching from smart to fast automatically after N seconds) which could apply to both the primary and the standby and which might also be workarounds for this problem, but this particular issue is specific to Hot Standby mode and pretending otherwise is just sticking your head in the sand. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 12 May 2010 09:15 On Wed, 2010-05-12 at 08:52 -0400, Robert Haas wrote: > On Wed, May 12, 2010 at 7:26 AM, Simon Riggs <simon(a)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. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stefan Kaltenbrunner on 12 May 2010 10:03
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 <simon(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |