Prev: [HACKERS] HS/SR and smart shutdown
Next: plpython3 perf
From: Josh Berkus on 29 Jan 2010 14:43
Fujii,

> I guess that the startup process and the walreceiver should wait
> for all read only backends to exit in smart shutdown case. It's
> because those backends might be waiting for the record that conflicts
> with their queries to be replayed. Is this OK? Or we should kill the
> startup process and the walreceiver on ahead?
>
> If my guess is right, we would need to add new PMState to cancel
> recovery and replication after all read only connections have died.

How could existing read queries on the slave be waiting on a WAL record?
I don't follow this.

--Josh Berkus


--
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: Heikki Linnakangas on 29 Jan 2010 16:04
Josh Berkus wrote:
>> I guess that the startup process and the walreceiver should wait
>> for all read only backends to exit in smart shutdown case. It's
>> because those backends might be waiting for the record that conflicts
>> with their queries to be replayed. Is this OK? Or we should kill the
>> startup process and the walreceiver on ahead?
>>
>> If my guess is right, we would need to add new PMState to cancel
>> recovery and replication after all read only connections have died.
>
> How could existing read queries on the slave be waiting on a WAL record?

Imagine that you do this in the master:

begin;
DROP TABLE foo (id int4);
< a lot of other stuff>
commit;

When the DROP is replayed in the standby, the startup process acquires a
lock on table foo, on behalf of the transaction that it's replaying. If
you run "SELECT * FROM foo" in the standby after that, it will block
until the startup process replays the COMMIT record and releases the lock.

This is similar to the deadlock situation in hot standby that was
discussed on the other thread, "Re: pgsql: In HS, Startup process sets
SIGALRM when waiting for buffer pin."

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.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: Simon Riggs on 29 Jan 2010 17:59
On Thu, 2010-01-21 at 09:27 +0200, Heikki Linnakangas wrote:

> Right, that's the way a standby server (= one still in recovery) has
> always behaved. It has made sense in the past: it's not in the spirit
> of smart shutdown to kill the WAL replay immediately. "smart" means
> wait for recovery to finish, then shutdown.
>
> It's a good question if that still makes sense with Hot Standby.
> Perhaps we should redefine smart shutdown in standby mode to shut down
> as soon as all read-only connections have died.

It's clear that "smart" shutdown doesn't work while something is active.
Recovery is "active" and so we shouldn't shutdown. It makes sense, it
works like this already, lets leave it. Document it if needed.

--
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: Josh Berkus on 29 Jan 2010 19:01

>> It's a good question if that still makes sense with Hot Standby.
>> Perhaps we should redefine smart shutdown in standby mode to shut down
>> as soon as all read-only connections have died.
>
> It's clear that "smart" shutdown doesn't work while something is active.
> Recovery is "active" and so we shouldn't shutdown. It makes sense, it
> works like this already, lets leave it. Document it if needed.

I don't think it's clear, or intuitive for users. In SR, recovery is
*never* done, so smart shutdown never completes (even if the master is
shut down, when I tested it). This is particularly an important issue
when you consider that some/many service and init scripts only use smart
shutdown ... so we'll get a lot of "bug reports" of "posgresql does not
shut down".

HOWEVER, I do believe this is an issue we could live with for 9.0 if
it's going to lead to a whole lot of additional debugging of SR. But if
it's an easy fix, it'll avoid a lot of complaints on pgsql-general.

--Josh Berkus

--
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 29 Jan 2010 19:05
On Fri, Jan 29, 2010 at 7:01 PM, Josh Berkus <josh(a)agliodbs.com> wrote:
>>> It's a good question if that still makes sense with Hot Standby.
>>> Perhaps we should redefine smart shutdown in standby mode to shut down
>>> as soon as all read-only connections have died.
>> It's clear that "smart" shutdown doesn't work while something is active.
>> Recovery is "active" and so we shouldn't shutdown. It makes sense, it
>> works like this already, lets leave it. Document it if needed.
> I don't think it's clear, or intuitive for users.  In SR, recovery is
> *never* done, so smart shutdown never completes (even if the master is
> shut down, when I tested it).  This is particularly an important issue
> when you consider that some/many service and init scripts only use smart
> shutdown ... so we'll get a lot of "bug reports" of "posgresql does not
> shut down".

Absolutely agreed. The existing smart shutdown behavior makes sense
from a certain point of view, but it doesn't seem very... what's the
word I'm looking for?... smart.

> HOWEVER, I do believe this is an issue we could live with for 9.0 if
> it's going to lead to a whole lot of additional debugging of SR.  But if
> it's an easy fix, it'll avoid a lot of complaints on pgsql-general.

Also agreed.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [HACKERS] HS/SR and smart shutdown
Next: plpython3 perf