On 2020/04/01 18:56, movead...@highgo.ca wrote:
>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.
Yes that is.
>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?
But where to emit it? I think it not so good by emitting to log file,
because the user will not check it everytime.
Yeah, I'm thinking to emit the message to log file, like the startup process
does in other places :)
BTW, why
CheckForStandbyTrigger() can not be called in backend.
Because
1) promote_signaled flag that IsPromoteSignaled() sees is set
only in the startup process
2) the trigger file can be removed or promote_trigger_file can be
changed after the backend detects it but before the startup process
does. That is, the result of the trigger file detection can be different
between the processes.
Of course we can change CheckForStandbyTrigger() so that it can
be called by backends, but I'm not sure if it's worth doing that.
Or another idea to reduce the delay between the request for
the promotion and the detection of it is to make the startup process
call CheckForStandbyTrigger() more frequently. Calling that every
replay of WAL record would be overkill and decrease the recovery
performance. Calling thst every WAL file might be ok. I'm not sure
if this is really improvement or not, though...
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
