Re: Re: Continue work on changes to recovery.conf API

Hi Peter, On 11/27/18 5:34 PM, Stephen Frost wrote: Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: On 27/11/2018 13:21, David Steele wrote: I would prefer a specific file that will be auto-included into postgresql.conf when present but be ignored when not present.

Re: Re: Continue work on changes to recovery.conf API

On 11/27/18 4:36 PM, Peter Eisentraut wrote: On 27/11/2018 13:21, David Steele wrote: I would prefer a specific file that will be auto-included into postgresql.conf when present but be ignored when not present. Some settings are generally ephemeral (recovery_target_time) and it would be nice

Re: Continue work on changes to recovery.conf API

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-11-27 15:36:59 +0100, Peter Eisentraut wrote: > > That might be a useful facility, but it wouldn't really address the > > pg_basebackup -R issue, because that creates settings that you don't > > want going away in this manner. > >

Re: Continue work on changes to recovery.conf API

Hi, On 2018-11-27 15:36:59 +0100, Peter Eisentraut wrote: > That might be a useful facility, but it wouldn't really address the > pg_basebackup -R issue, because that creates settings that you don't > want going away in this manner. Why is that / which are those? It's not like it worked like

Re: Continue work on changes to recovery.conf API

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 27/11/2018 13:21, David Steele wrote: > > I would prefer a specific file that will be auto-included into > > postgresql.conf when present but be ignored when not present. Some > > settings are generally ephemeral

Re: Continue work on changes to recovery.conf API

On 27/11/2018 13:21, David Steele wrote: > I would prefer a specific file that will be auto-included into > postgresql.conf when present but be ignored when not present. Some > settings are generally ephemeral (recovery_target_time) and it would be > nice for them to go away. When recovery is

Re: Continue work on changes to recovery.conf API

On 11/27/18 3:59 AM, Peter Eisentraut wrote: > On 25/11/2018 21:39, Andres Freund wrote: >> On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: >>> - User performs a backup with pg_basebackup -R >>> - Replica is then promoted to be a primary >>> - User performs a backup with pg_basebackup -R on the

Re: Continue work on changes to recovery.conf API

On 25/11/2018 21:39, Andres Freund wrote: > On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: >> - User performs a backup with pg_basebackup -R >> - Replica is then promoted to be a primary >> - User performs a backup with pg_basebackup -R on the new primary >> - Duplicate entries end up in

Re: Continue work on changes to recovery.conf API

On Sun, Nov 25, 2018 at 04:56:13PM +0100, Peter Eisentraut wrote: > Committed with that addition. Thanks for adding that! -- Michael signature.asc Description: PGP signature

Re: Continue work on changes to recovery.conf API

Greetings, * Sergei Kornilov (s...@zsrv.org) wrote: > > Why don't we put recovery entries into postgresql.recovery.conf or such? > > And overwrite rather than append? > Appending to postgressql.auto.conf instead of writing new hardcoded file was > proposed here: >

Re: Continue work on changes to recovery.conf API

Hi, On 25/11/2018 21:48, Stephen Frost wrote: > Greetings, > > On Sun, Nov 25, 2018 at 15:39 Andres Freund > wrote: > > Hi, > > On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: > > - User performs a backup with pg_basebackup -R > > - Replica is

Re: Continue work on changes to recovery.conf API

Hi > Why don't we put recovery entries into postgresql.recovery.conf or such? > And overwrite rather than append? Appending to postgressql.auto.conf instead of writing new hardcoded file was proposed here:

Re: Continue work on changes to recovery.conf API

Greetings, On Sun, Nov 25, 2018 at 15:39 Andres Freund wrote: > Hi, > > On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: > > - User performs a backup with pg_basebackup -R > > - Replica is then promoted to be a primary > > - User performs a backup with pg_basebackup -R on the new primary > >

Re: Continue work on changes to recovery.conf API

On 2018-11-25 16:56:13 +0100, Peter Eisentraut wrote: > On 21/11/2018 07:00, Michael Paquier wrote: > >> Author: Simon Riggs > >> Author: Abhijit Menon-Sen > >> Author: Sergei Kornilov > > I think that Fujii Masao should also be listed as an author, or at least > > get a mention. He was one of

Re: Continue work on changes to recovery.conf API

Hi, On 2018-11-25 13:24:15 -0500, Stephen Frost wrote: > - User performs a backup with pg_basebackup -R > - Replica is then promoted to be a primary > - User performs a backup with pg_basebackup -R on the new primary > - Duplicate entries end up in postgresql.auto.conf. Ew. Why don't we put

Re: Continue work on changes to recovery.conf API

Peter Eisentraut writes: > Committed with that addition. Some of the buildfarm doesn't like this. I realized that the common denominator was EXEC_BACKEND: if you build with -DEXEC_BACKEND the failure is completely reproducible. Presumably something is thinking that it will inherit some

Re: Continue work on changes to recovery.conf API

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > Committed with that addition. I'm concerned that this hasn't been entirely thought through regarding pretty common use-cases, consider a pretty typical pg_basebackup -R usage case: - User performs a backup with

Re: Continue work on changes to recovery.conf API

HelloThank you! Regards, Sergei

Re: Continue work on changes to recovery.conf API

On 21/11/2018 07:00, Michael Paquier wrote: >> Author: Simon Riggs >> Author: Abhijit Menon-Sen >> Author: Sergei Kornilov > I think that Fujii Masao should also be listed as an author, or at least > get a mention. He was one of the first to work on this stuff. Committed with that addition.

Re: Continue work on changes to recovery.conf API

On Wed, Nov 21, 2018 at 12:58:19PM +0100, Peter Eisentraut wrote: > This wasn't my idea, so this is just my interpretation. The scenario > I'm wondering about is: You have a standby. So (under your system) you > set standby_mode=on and create recovery.trigger. Then you promote that > standby,

Re: Continue work on changes to recovery.conf API

On 21/11/2018 07:00, Michael Paquier wrote: > What's bad in keeping standby_mode and just rely on recovery.signal to > enforce recovery to happen? When the startup process starts all the > parameters should be loaded. That would also need less work from users > to switch to the new APIs. I

Re: Continue work on changes to recovery.conf API

On Tue, Nov 20, 2018 at 12:07:12PM +0100, Peter Eisentraut wrote: > I went over the patch and did a bunch of small refinements. I have also > updated the documentation more extensively. The attached patch is > committable to me. Thanks for putting energy into that. > Recovery is now initiated

Re: Continue work on changes to recovery.conf API

Hello Thank you! Here is patch update addressing your comments. > - useless whitespace change in xlog.c Oops, did not notice. Fixed. > - I think we can drop logRecoveryParameters(). Users can now inspect > those parameters using the normal GUC mechanisms. (They were all DEBUG2 > anyway, so it's

Re: Continue work on changes to recovery.conf API

On 30/10/2018 14:30, Sergei Kornilov wrote: > I attached new version of this patch due merge conflict with pg_promote > function. This patch looks pretty good to me functionality-wise. There are some code details to work through, listed below. In this review, I'm skipping over your

Re: Continue work on changes to recovery.conf API

On Fri, Sep 28, 2018 at 4:20 PM Peter Eisentraut wrote: > > - recovery_target (immediate), recovery_target_name, recovery_target_time, > > recovery_target_xid, recovery_target_lsn are replaced to > > recovery_target_type and recovery_target_value (was discussed and changed > > in previous

Re: Continue work on changes to recovery.conf API

Hi I attached new version of this patch due merge conflict with pg_promote function. regards, Sergeidiff --git a/contrib/pg_standby/pg_standby.c b/contrib/pg_standby/pg_standby.c index ee1fbd7..946239c 100644 --- a/contrib/pg_standby/pg_standby.c +++ b/contrib/pg_standby/pg_standby.c @@ -611,7

Re: Continue work on changes to recovery.conf API

Hello I complete new version of this patch. I've attached it. In this version i remove proposed recovery_target_type/recovery_target_value and implement set of current settings: recovery_target (immediate), recovery_target_name, recovery_target_time, recovery_target_xid, recovery_target_lsn

Re: Continue work on changes to recovery.conf API

Hello thank you for review! >>  - if present both standby.signal and recovery.signal - we use standby mode >>  (this design from previous thread) > > Didn't find the discussion on that and don't understand the reasons, but > seems OK and easy to change if we don't like it. I meant this was

Re: Continue work on changes to recovery.conf API

Andres Freund writes: > On 2018-09-28 16:36:35 -0400, Tom Lane wrote: >> No, they MUST be independently verifiable. The interactions between >> the check_xxx functions in this patch are utterly unsafe. We've >> learned that lesson before. > I'm not sure those concerns apply quite the same way

Re: Continue work on changes to recovery.conf API

Hi, On 2018-09-28 16:36:35 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > I think this was the major point of contention. I reread the old > > thread, and it's still not clear why we need to change this. _type and > > _value look like an EAV system to me. GUC variables should be > >

Re: Continue work on changes to recovery.conf API

Peter Eisentraut writes: > I think this was the major point of contention. I reread the old > thread, and it's still not clear why we need to change this. _type and > _value look like an EAV system to me. GUC variables should be > verifiable independent of another variable. No, they MUST be

Re: Continue work on changes to recovery.conf API

On 29/08/2018 17:43, Sergei Kornilov wrote: > Current patch moves recovery.conf settings into GUC system: > - if startup process found recovery.conf - it throw error OK > - recovery mode is turned on if new special file recovery.signal found OK > - standby_mode setting was removed. Standby

Re: Continue work on changes to recovery.conf API

Hello Current patch moves recovery.conf settings into GUC system: - if startup process found recovery.conf - it throw error - recovery mode is turned on if new special file recovery.signal found - standby_mode setting was removed. Standby mode can be enabled if startup found new special file

Re: Continue work on changes to recovery.conf API

On 01/07/2018 13:45, Sergei Kornilov wrote: > Commitfest 2018-09 is now open and, as planned, i create one entry: > https://commitfest.postgresql.org/19/1711/ > Also i attach new version due merge conflict with HEAD. Could you please describe in detail what this current patch does? -- Peter

Re: Continue work on changes to recovery.conf API

On 22 June 2018 at 02:48, Sergei Kornilov wrote: > I completely forgot attach patch, sorry. Attached now Sergei, It's great to see you picking this up. I'll try to find time to review this for the next CF cycle. Please poke me if you don't hear from me, I do get distracted. It's long past

Continue work on changes to recovery.conf API

Hello all I would like to continue work on new recovery api proposed in thread [1]. We have some form of consensus but thread has been inactive for a long time and i hope i can help. I start from last published patch [2] and make some changes: - updated to current HEAD - made the patch pass