On 2020/04/01 17:58, movead...@highgo.ca wrote:
Thanks for the explanation again! Maybe I understand your point.
Great.
As far as I read the code, in the standby mode, the startup process
periodically checks the trigger file in WaitForWALToBecomeAvailable().
No?
Yes it is.
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.
If there be a huge number of wal segments need a standby to rewind,
then it can not be a 'small delay'.
Yeah, that's true.
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?
I want to point out the thing, the pg_wal_replay_pause() shows success but
the startup process keeping redo, it may cause something confused. So it's
better to solve the issue.
This happens because the startup process detects the trigger file
after pg_wal_replay_pause() succeeds, and then make the recovery
get out of the paused state. It might be problematic to end the paused
state silently? So, to make the situation less confusing, what about
emitting a log message when ending the paused state because of
the promotion?
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
