Re: Turning recovery.conf into GUCs - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Turning recovery.conf into GUCs
Date
Msg-id 54738EEC.7020706@agliodbs.com
Whole thread Raw
In response to Re: Turning recovery.conf into GUCs  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Turning recovery.conf into GUCs  (Alex Shulgin <ash@commandprompt.com>)
Re: Turning recovery.conf into GUCs  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 11/24/2014 09:24 AM, Jaime Casanova wrote:
>> ... I don't honestly think we need a 4th method for promotion.
>>
> 
> this is not for promotion, this is to force postgres to start in
> recovery mode and read recovery configuration parameters.
> 
>> The main reason to want a "we're in recovery file" is for PITR rather
>> than for replication, where it has a number of advantages as a method,
>> the main one being that recovery.conf is unlikely to be overwritten by
>> the contents of the backup.
>>
> 
> only that you need to start in recovery mode to start replication

Right, but my point is that having a trigger file *is not necessary for
replication, only for PITR* -- and maybe not necessary even for PITR.
That is, in a streaming replication configuration, having a
"standby_mode = on|off" parameter is 100% sufficient to control
replication with the small detail that "pg_ctl promote" needs to set it
in pg.auto.conf or conf.d.

And, now, having given it some thought, I'm going to argue that it's not
required for PITR either, provided that we can use the auto.conf method.

Before I go into my ideas, though, what does the current patch do
regarding non-replication PITR?

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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: polymorphic types - enforce casting to most common type automatically
Next
From: Josh Berkus
Date:
Subject: Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs