On Mon, Nov 24, 2014 at 12:24 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
> On Fri, Nov 21, 2014 at 12:55 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 11/21/2014 09:35 AM, Alex Shulgin wrote:
>>> Hello,
>>>
>>> Here's an attempt to revive this patch.
>>
>> Yayy! Thank you.
>>
>>>> People might not like me for the suggestion, but I think we should
>>>> simply always include a 'recovery.conf' in $PGDATA
>>>> unconditionally. That'd make this easier.
>>>> Alternatively we could pass a filename to --write-recovery-conf.
>>>
>>> Well, the latest version of this patch fails to start when it sees
>>> 'recovery.conf' in PGDATA:
>>>
>>> FATAL: "recovery.conf" is not supported anymore as a recovery method
>>> DETAIL: Refer to appropriate documentation about migration methods
>>>
>>> I've missed all the discussion behind this decision and after reading
>>> the ALTER SYSTEM/conf.d thread I'm even more confused so I'd like
>>> someone more knowledgeable to speak up on the status of this.
>>
>> The argument was that people wanted to be able to have an empty
>> recovery.conf file as a "we're in standby" trigger so that they could
>> preserve backwards compatibility with external tools. I don't agree
>> with this argument, but several people championed it.
>>
>
> well, my approach was that postgres just ignore the file completely. I
> mean, recovery.conf will no longer mean anything special.
> Then, every tool that create recovery.conf in $PGDATA only has to add
> an ALTER SYSTEM to include it
>
i mean ALTER SYSTEM in master before copying or just add the line in
postgresql.conf
but, as the patch shows agreement was to break backwards compatibility
and fail to start if the file is present
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157