Date: Wed, 11 Dec 2013 22:47:12 +0100
From: Andres Freund <andres@2ndquadrant.com>
To: =?iso-8859-1?Q?Fabr=EDzio?= de Royes Mello <fabriziomello@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>,
 KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>,
 Robert Haas <robertmhaas@gmail.com>,
 Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Time-Delayed Standbys
Message-ID: <20131211214712.GA536@awork2.anarazel.de>
References: 
 <CA+TgmoaCL4G+YotjjjFM+J_h0nSkp4gXiiBPDQGHxTcc_T0w-w@mail.gmail.com>
 <CAFcNs+r-GyizHAPDvRz=3XR3BYLUqxpqxrvJq8spk4PJe5hxAA@mail.gmail.com>
 <52A59D10.7020209@lab.ntt.co.jp> <52A5A095.5020002@lab.ntt.co.jp>
 <20131209112937.GA27840@awork2.anarazel.de>
 <52A697F3.8030403@lab.ntt.co.jp>
 <20131210093848.GG27840@awork2.anarazel.de>
 <52A807F5.4020203@lab.ntt.co.jp>
 <CA+U5nMKoiXbX2iPJSEyxYiT2M2KBXbZcbi2BQAXVZr+eSFQD-g@mail.gmail.com>
 <CAFcNs+qPYEzJ-jRBH31VppG=_F1-9gwR_T2iRqru-i-4rdRLrA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: 
 <CAFcNs+qPYEzJ-jRBH31VppG=_F1-9gwR_T2iRqru-i-4rdRLrA@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2013-12-11 16:37:54 -0200, Fabr=EDzio de Royes Mello wrote:
> On Wed, Dec 11, 2013 at 6:27 AM, Simon Riggs <simon@2ndquadrant.com> wrot=
e:
> > >> I think this feature will be used in a lot of scenarios in
> > >> which PITR is currently used.
> > >
> > > We have to judge which is better, we get something potential or to pr=
otect
> > > stupid.
> > > And we had better to wait author's comment...
> >
> > I'd say just document that it wouldn't make sense to use it for PITR.
> >
> > There may be some use case we can't see yet, so specifically
> > prohibiting a use case that is not dangerous seems too much at this
> > point. I will no doubt be reminded of these words in the future...

> I tend to agree with Simon, but I confess that I don't liked to delay a
> server with standby_mode =3D 'off'.

> The main goal of this patch is delay the Streaming Replication, so if the
> slave server isn't a hot-standby I think makes no sense to delay it.

> Mitsumasa suggested to add "StandbyModeRequested" in conditional branch to
> skip this situation. I agree with him!

I don't think that position has any merit, sorry: Think about the way
this stuff gets setup. The user creates a new basebackup (pg_basebackup,
manual pg_start/stop_backup, shutdown primary). Then he creates a
recovery conf by either starting from scratch, using
--write-recovery-conf or by copying recovery.conf.sample. In none of
these cases delay will be configured.

So, with that in mind, the only way it could have been configured is by
the user *explicitly* writing it into recovery.conf. And now you want to
to react to this explicit step by just *silently* ignoring the setting
based on some random criteria (arguments have been made about
hot_standby=3Don/off, standby_mode=3Don/off which aren't directly
related). Why on earth would that by a usability improvement?

Also, you seem to assume there's no point in configuring it for any of
hot_standby=3Doff, standby_mode=3Doff, recovery_target=3D*. Why? There's
usecases for all of them:
* hot_standby=3Doff: Makes delay useable with wal_level=3Darchive (and thus
  a lower WAL volume)
* standby_mode=3Doff: Configurations that use tools like pg_standby and
  similar simply don't need standby_mode=3Don. If you want to trigger
  failover from within the restore_command you *cannot* set it.
* recovery_target_*: It can still make sense if you use
  pause_at_recovery_target.

In which scenarios does your restriction actually improve anything?

Greetings,

Andres Freund

--=20
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers