On Fri, 2010-01-08 at 12:41 +0200, Heikki Linnakangas wrote:
let's make the default no failover if no trigger file
location is configured, and remove the notion that normal shutdown of
master stops recovery.
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers
The trigger file logic feels a bit backwards. As the patch stands, when
the standby starts up, it retries connecting to the master server
indefinitely, until a connection is successfully established. Then it
streams until the connection breaks. If the connection is dropped
abruptly, because of a
On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The trigger file logic feels a bit backwards. As the patch stands, when
the standby starts up, it retries connecting to the master server
indefinitely, until a connection is successfully established.
Magnus Hagander wrote:
On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So the trigger file is really a holdoff file, like a safety catch on a
gun. At the very least it should be renamed, but I don't think that's a
very useful behavior anyway.
It
On Fri, Jan 8, 2010 at 7:41 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Thinking more clearly, my comment above about the trigger file logic
being backwards was bollocks; if the master is shut down, standby waits
for the trigger file to appear, not to go away. And creating
Fujii Masao wrote:
You dropped CheckForStandbyTrigger() called at the end of recovery.
I think that this would be problem when an invalid record is found before
we reaches a streaming recovery state. The standby would be out-of-control
of the clusterware, and be brought up. Which might cause a
On Fri, Jan 8, 2010 at 10:31 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
You dropped CheckForStandbyTrigger() called at the end of recovery.
I think that this would be problem when an invalid record is found before
we reaches a streaming recovery state.
