Re: beta3 & the open items list - Mailing list pgsql-hackers

From Robert Haas
Subject Re: beta3 & the open items list
Date
Msg-id AANLkTimIEupLCgS2HLjTssh0zEuvA9J2P38diH5Hz2o5@mail.gmail.com
Whole thread Raw
In response to Re: beta3 & the open items list  (Greg Stark <gsstark@mit.edu>)
Responses Re: beta3 & the open items list  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: beta3 & the open items list  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Sat, Jun 19, 2010 at 2:46 PM, Greg Stark <gsstark@mit.edu> wrote:
> On Sat, Jun 19, 2010 at 2:43 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 4. Streaming Replication needs to detect death of master.  We need
>> some sort of keep-alive, here.  Whether it's at the TCP level (as
>> advocated by Tom Lane and others) or at the protocol level (as
>> advocated by Greg Stark) is something that we have yet to decide; once
>> it's decided, someone will need to do it...
>
> This sounds like a useful feature but I don't see why it's not 9.1
> material. The status quo is that the expected usage pattern is manual
> failover. As long as the slave responds to manual intervention when in
> this state I don't think this is a blocking issue. Monitoring and
> automatic failover are clearly things we plan to add features to
> handle better in the future.

Right now, if the SR master reboots unexpectedly (say, power plug pull
and restart), the slave never notices.  It just sits there forever
waiting for the next byte of data from the master to arrive (which it
never will).  You have to manually restart the server or hit
walreceiver with a SIGTERM to get it to start streaming agian.  I
guess we could decide we're just not going to deal with that, but it
seems like a fairly large misfeature to me.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: beta3 & the open items list
Next
From: Andrew Dunstan
Date:
Subject: Re: extensible enum types