>But, sorry,,, I failed to understand the issue that you reported, yet... >You mean that the first call of pg_wal_replay_pause() in the step #2 >should check whether the trigger file exists or not? If so, could you >tell me why we should do that? Sorry about my pool english. The 'pg_wal_replay_pause()' is executed in step 4. I mention it in step 2 is for explain why it need lots of insert data.
>BTW, right now only the startup process is allowed to call >CheckForStandbyTrigger(). So the backend process calling >pg_wal_replay_pause() and PromoteIsTriggered() is not allowed to call >CheckForStandbyTrigger(). The current logic is that the startup process >is responsible for checking the trigger file and set the flag in the shmem It's here, startup process does not call CheckForStandbyTrigger() to check the trigger file until a pg_wal_replay_pause() or PromoteIsTriggered() comes, so first time to call the pg_wal_replay_pause(), it use a wrong 'SharedPromoteIsTriggered' value. >if promotion is triggered. Then other processes like backend know >whether promotion is ongoing or not from the shmem. So basically >the backend doesn't need to check the trigger file itself. If backend is not allowed to call CheckForStandbyTrigger(), then you should find a way to hold it. In another word, during the recovery if I add the trigger file, the starup process do not know it at all until after a pg_wal_replay_pause() come. In addition, although the first time I exec 'pg_wal_replay_pause' it shows success, the startup process is keeping redo(no stop). Regards, Highgo Software (Canada/China/Pakistan) URL : www.highgo.ca EMAIL: mailto:movead(dot)li(at)highgo(dot)ca
