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
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 |