Re: Dividing progress/debug information in pg_standby, and stat before copy

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Date: 2010-01-26 10:55:04
Message-ID: 1264503304.24669.4902.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-01-26 10:56:04 Re: Dividing progress/debug information in pg_standby, and stat before copy
Previous Message Dimitri Fontaine 2010-01-26 10:47:10 Re: Dividing progress/debug information in pg_standby, and stat before copy