Skip site navigation (1) Skip section navigation (2)

Re: beta3 & the open items list

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: beta3 & the open items list
Date: 2010-06-19 18:53:40
Message-ID: AANLkTimIEupLCgS2HLjTssh0zEuvA9J2P38diH5Hz2o5@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jun 19, 2010 at 2:46 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Sat, Jun 19, 2010 at 2:43 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-06-19 18:58:59
Subject: Re: extensible enum types
Previous:From: Greg StarkDate: 2010-06-19 18:46:57
Subject: Re: beta3 & the open items list

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group