Re: Dividing progress/debug information in pg_standby, and stat before copy - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Dividing progress/debug information in pg_standby, and stat before copy
Date
Msg-id 1264503304.24669.4902.camel@ebony
Whole thread Raw
In response to Re: Dividing progress/debug information in pg_standby, and stat before copy  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Dividing progress/debug information in pg_standby, and stat before copy
List pgsql-hackers
On Tue, 2010-01-26 at 12:12 +0200, Heikki Linnakangas wrote:
> Magnus Hagander wrote:
> > I think there are definite use-cases for pg_standby as well, even when
> > we have SR. SR requires you to have a reasonably reliable network
> > connection that lets you do an arbitrary TCP connection. There are a
> > lot of scenarios that could still use the
> > "here's-a-file-you-choose-how-to-get-it-over-to-the-other-end" style
> > transfer, and that don't necessarily care that there is a longer
> > delay.
> 
> With the changes to the retry-logic that were discussed (see
> http://archives.postgresql.org/message-id/4B5758ED.1060703@enterprisedb.com,
> I intend to commit that tomorrow), if standby_mode=on, the server will
> keep retrying to restore the next segment using restore_command until
> it's found, or the trigger file is found.
> 
> *That* makes pg_standby obsolete, not streaming replication per se.
> Setting standby_mode=on, with a valid restore_command using e.g 'cp' and
> no connection info for walreceiver is more or less the same as using
> pg_standby.

It could be, but that is not what you've mentioned before and I don't
think its that simple.

If no connection info is set we use existing defaults and attempt that.
ISTM there is no way to set connection info to be "unset", or to request
that it doesn't keep continually retrying. Currently, we had presumed
that standby_mode = off would be the same as Warm Standby replication,
using pg_standby or other.

pg_standby checks file size before returning. If you just use "cp" as
suggested then it would fail because the copy would start before the
file is ready to be copied.

I'm not against including pg_standby features in backend, as long as you
provide *all* of the features and test that mode of operation. Even so,
you're still likely to remove something someone currently thinks
important.

Please don't be so quick to slam the door on previous ways of working.
When sync rep fails, I would not wish to find that the parachute has
been removed to keep the balloon tidy or that the hole at the top has
been widened to improve the view.

That isn't an argument to spend further time on pg_standby, but if
people feel its important and they have time, I would not stop them.

-- Simon Riggs           www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Next
From: Heikki Linnakangas
Date:
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy