|To:||"Sergei Kornilov" <sk(at)zsrv(dot)org>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: recovery_target_action=pause with confusing hint|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 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.
Highgo Software (Canada/China/Pakistan)
URL : www.highgo.ca
|Next Message||Tomas Vondra||2020-04-01 02:44:24||Re: [PATCH] Incremental sort (was: PoC: Partial sort)|
|Previous Message||Bruce Momjian||2020-04-01 02:26:38||Re: Issues with building cpp extensions on PostgreSQL 10+|