Re: max_standby_delay considered harmful

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Florian Pflug <fgp(at)phlo(dot)org>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: max_standby_delay considered harmful
Date: 2010-05-12 14:03:31
Message-ID: 4BEAB533.7060302@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2010-05-12 14:14:53 Re: Query execution plan from 8.3 -> 8.4
Previous Message Simon Riggs 2010-05-12 13:15:11 Re: max_standby_delay considered harmful