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

Re: [PATCH] Make pg_basebackup configure and start standby

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>
Subject: Re: [PATCH] Make pg_basebackup configure and start standby
Date: 2012-07-01 15:44:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, Jul 1, 2012 at 1:02 PM, Boszormenyi Zoltan <zb(at)cybertec(dot)at> wrote:
> Hi,
> attached is a patch that does $SUBJECT.
> It's a usability enhancement, to take a backup, write
> a minimalistic recovery.conf and start the streaming
> standby in one go.

I like the writing of recovery.conf. In fact, I had it in my code at
one very early point and took it out in order to get a clean patch
ready :)

But I think that part is lacking in functionality: AFAICT it's
hardcoded to only handle host, port, user and password. What about
other connection parameters, likely passed to pg_basebackup through
the environment in that case? isn't that quite likely to break the
server later?

Maybe the proper way around that is to provide the ability for
pg_basebackup to take a full connection string, just like we allow
psql to do?

I'm not sure we should go the way of providing the "start slave".
Given thta how you want to start the slave differs so much on
platforms. The most glaring example is on windows you really need to
*start the service* rather than use pg_ctl. Sure, you can document
your way around that, but I'm not sure the functionality added is
really worth it. What about all the other potential connection

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2012-07-01 15:51:54
Subject: Re: [PATCH 14/16] Add module to apply changes from an apply-cache using low-level functions
Previous:From: Boszormenyi ZoltanDate: 2012-07-01 15:42:41
Subject: Re: [PATCH] Make pg_basebackup configure and start standby

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