Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown)
Paul Guo <pguo@pivotal.io>
From: Paul Guo <pguo@pivotal.io>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>,
Thomas Munro <thomas.munro@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
Jimmy Yih <jyih@pivotal.io>, Ashwin Agrawal <aagrawal@pivotal.io>
Date: 2019-09-09T14:18:49Z
Lists: pgsql-hackers
> > Thank for rebasing. > > I didn't like 0001 very much. > > * It seems now would be the time to stop pretending we're using a file > called recovery.conf; I know we still support older server versions that > use that file, but it sounds like we should take the opportunity to > rename the function to be less misleading once those versions vanish out > of existance. > How about renaming the function names to GenerateRecoveryConf -> GenerateRecoveryConfContents WriteRecoveryConf -> WriteRecoveryConfInfo <- it writes standby.signal on pg12+, so function name WriteRecoveryConfContents is not accurate. and variable writerecoveryconf -> write_recovery_conf_info? > * disconnect_and_exit seems a bit out of place compared to the other > parts of this new module. I think you only put it there so that the > 'conn' can be a global, and that you can stop passing 'conn' as a > variable to GenerateRecoveryConf. It seems more modular to me to keep > it as a separate variable in each program and have it passed down to the > routine that writes the file. > > * From modularity also seems better to me to avoid a global variable > 'recoveryconfcontents' and instead return the string from > GenerateRecoveryConf to pass as a param to WriteRecoveryConf. > (In fact, I wonder why the current structure is like it is, namely to > have ReceiveAndUnpackTarFile write the file; why wouldn't be its caller > be responsible for writing it?) > Reasonable to make common code include less variables. I can try modifying the patches to remove the previously added variables below in the common code. +/* Contents of configuration file to be generated */ +extern PQExpBuffer recoveryconfcontents; + +extern bool writerecoveryconf; +extern char *replication_slot; +PGconn *conn; > > I wonder about putting this new file in src/fe_utils instead of keeping > it in pg_basebackup and symlinking to pg_rewind. Maybe if we make it a > true module (recovery_config_gen.c) it makes more sense there. > > I thought some about where to put the common code also. It seems pg_rewind and pg_basebackup are the only consumers of the small common code. I doubt it deserves a separate file under src/fe_utils. > > 0003: > > I still don't understand why we need a command-line option to do this. > Why should it not be the default behavior? > This was discussed but frankly speaking I do not know how other postgres users or enterprise providers handle this (probably some have own scripts?). I could easily remove the option code if more and more people agree on that or at least we could turn it on by default? Thanks
Commits
-
Improve test coverage of pg_rewind
- 55ba56415bae 13.0 landed
-
Improve handling and coverage of --no-ensure-shutdown in pg_rewind
- caa078353ecd 13.0 landed
-
Fix issues in pg_rewind with --no-ensure-shutdown/--write-recovery-conf
- 6837632b758e 13.0 landed
-
Fix --dry-run mode of pg_rewind
- c2e3b311d9ef 12.1 landed
- 6f3823b03560 13.0 landed
-
pg_rewind: test new --write-recovery-conf functionality
- 7524c788743f 13.0 landed
-
pg_rewind: Allow writing recovery configuration
- 927474ce1a24 13.0 landed
-
Have pg_rewind run crash recovery before rewinding
- 5adafaf176d0 13.0 landed
-
Split out recovery confing-writing code from pg_basebackup
- caba97a9d9f4 13.0 landed
-
Switch TAP tests of pg_rewind to use non-superuser role, take two
- d9f543e9e9be 12.0 cited