Re: recovery_target_action=pause with confusing hint

On 2020/04/01 16:53, movead(dot)li(at)highgo(dot)ca wrote:
>
>>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.

Thanks for the explanation again! Maybe I understand your point.

As far as I read the code, in the standby mode, the startup process
periodically checks the trigger file in WaitForWALToBecomeAvailable().
No?

There can be small delay between the creation of the trigger file
and the periodic call to CheckForStandbyTrigger() by the startup process.
If you execute pg_wal_replay_pause() during that delay, it would suceed.

But you'd like to get rid of that delay completely? In other words,
both the startup process and the backend calling pg_wal_replay_pause()
should detect the existence of the trigger file immdiately after
it's created?

Regards,

--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters