Re: Streaming replication - unable to stop the standby

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication - unable to stop the standby
Date: 2010-05-03 18:26:14
Message-ID: 4BDF1546.7000407@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Mon, May 3, 2010 at 2:04 PM, Stefan Kaltenbrunner
> <stefan(at)kaltenbrunner(dot)cc> wrote:
>> I'm currently testing SR/HS in 9.0beta1 and I noticed that it seems quite
>> easy to end up in a situation where you have a standby that seems to be
>> stuck in:
>>
>> $ psql -p 5433
>> psql: FATAL: the database system is shutting down
>>
>> but not not actually shuting down ever. I ran into that a few times now
>> (mostly because I'm trying to chase a recovery issue I hit during earlier
>> testing) by simply having the master iterate between a pgbench run and
>> "idle" while simple doing pg_ctl restart in a loop on the standby.
>> I do vaguely recall some discussions of that but I thought the issue git
>> settled somehow?
>
> Yes - I thought it was too. Specifically, I thought I fixed it. The
> default mode is 'smart' shutdown, just as it is on the primary, so it
> won't shut down until all clients have disconnected, but it should
> work provided you don't leave a session somewhere. Can you describe
> steps to reproduce?

well this is basically master and standby on the same box - with the
master doing short pgbench interleaved with a "sleep 20", the standby is
doing nothing in terms of queries and just executing pg_ctl restart in a
loop(simulating a typical maintainance reboot of a standby).

Stefan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2010-05-03 18:37:36 Re: max_standby_delay considered harmful
Previous Message Alvaro Herrera 2010-05-03 18:22:35 Re: missing file in git repo