>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
