Re: [PATCH] Make pg_basebackup configure and start standby

From: Hans-Jürgen Schönig <hs(at)cybertec(dot)at>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Make pg_basebackup configure and start standby
Date: 2012-07-01 19:13:26
Message-ID: 881AF06B-DF0A-4E78-822B-C51C7E172606@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jul 1, 2012, at 5:44 PM, Magnus Hagander wrote:

> 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?
>

one option would be to check the environments and take them if needed.
however, i am not sure if this is a good idea either - just thing of PGPASSWORD or so. do we really want to take it and write it to a file straight away? i guess there are arguments for both ideas.

still, i guess your argument is a reasonable one.

> 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?
>

this would make things redundant. i am quite sure some users might not get the distinction straight away.

>
>
> 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
> parameters.

regards,

hans

--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2012-07-01 19:20:58 Re: Support for array_remove and array_replace functions
Previous Message Nils Goroll 2012-07-01 19:02:05 Re: Update on the spinlock->pthread_mutex patch experimental: replace s_lock spinlock code with pthread_mutex on linux