Re: Turning recovery.conf into GUCs

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Alex Shulgin <ash(at)commandprompt(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Turning recovery.conf into GUCs
Date: 2014-12-02 18:59:49
Message-ID: 547E0C25.1010207@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/02/2014 10:31 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 12/02/2014 06:25 AM, Alex Shulgin wrote:
>
>>> Whatever tricks we might employ will likely
>>> be defeated by the fact that the oldschool user will fail to *include*
>>> recovery.conf in the main conf file.
>>
>> Well, can we merge this patch and then fight out what to do for the
>> transitional users as a separate patch?
>
> You seem to be saying "I don't have any good idea how to solve this
> problem now, but I will magically have one once this is committed". I'm
> not sure that works very well.

No, I'm saying "this problem is easy to solve technically, but we have
intractable arguments on this list about the best way to solve it, even
though the bulk of the patch isn't in dispute".

> In any case, the proposal upthread that we raise an error if
> recovery.conf is found seems sensible enough. Users will see it and
> they will adjust their stuff -- it's a one-time thing. It's not like
> they switch a version forwards one week and back the following week.

I'm OK with that solution. Apparently others aren't though.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-12-02 19:02:07 Re: How about a option to disable autovacuum cancellation on lock conflict?
Previous Message Alvaro Herrera 2014-12-02 18:35:21 Re: How about a option to disable autovacuum cancellation on lock conflict?