>> When I test the patch, I find an issue: I start a stream with >> 'promote_trigger_file' >> GUC valid, and exec pg_wal_replay_pause() during recovery and as below it >> shows success to pause at the first time. I think it use a initialize >> 'SharedPromoteIsTriggered' value first time I exec the pg_wal_replay_pause(). >hm. Are you sure this is related to this patch? Could you explain the exact >timing? I mean log_statement = all and relevant logs. >Most likely this is expected change by >https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=496ee647ecd2917369ffcf1eaa0b2cdca07c8730 > >My proposal does not change the behavior after this commit, only changing the >lines in the logs. I test it again with (92d31085e926253aa650b9d1e1f2f09934d0ddfc), and the issue appeared again. Here is my test method which quite simple: 1. Setup a base backup by pg_basebackup. 2. Insert lots of data in master for the purpose I have enough time to exec pg_wal_replay_pause() when startup the replication. 3. Configure the 'promote_trigger_file' GUC and create the trigger file. 4. Start the backup(standby), connect it immediately, and exec pg_wal_replay_pause() Then it appears, and a test log attached.
I means when I exec the pg_wal_replay_pause() first time, nobody has check the trigger state by CheckForStandbyTrigger(), it use a Initialized 'SharedPromoteIsTriggered' value. And patch attached can solve the issue. Regards, Highgo Software (Canada/China/Pakistan) URL : www.highgo.ca EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
pg_wal_replay_pause_issue.patch
Description: Binary data
postgresql-2020-04-01_100849.log
Description: Binary data
