On 2020/03/25 19:42, Sergei Kornilov wrote:
> Hi
>
>>> Could we add a few words in func.sgml to clarify the behavior? Especially for users from my example above.
Somethinglike:
>>>
>>>> If a promotion is triggered while recovery is paused, the paused state ends, replay of any WAL immediately
availablein the archive or in pg_wal will be continued and then a promotion will be completed.
>>
>> This description is true if pause is requested by pg_wal_replay_pause(),
>> but not if recovery target is reached and pause is requested by
>> recovery_target_action=pause. In the latter case, even if there are WAL data
>> avaiable in pg_wal or archive, they are not replayed, i.e., the promotion
>> completes immediately. Probably we should document those two cases
>> explicitly to avoid the confusion about a promotion and recovery pause?
>
> This is description for pg_wal_replay_pause, but actually we suggest to call pg_wal_replay_resume in
recovery_target_action=pause...So, I agree, we need to document both cases.
>
> PS: I think we have inconsistent behavior here... Read wal during promotion from local pg_wal AND call
restore_command,but ignore walreceiver also seems strange for my DBA hat...
If we don't ignore walreceiver and does try to connect to the master,
a promotion and recovery cannot end forever since new WAL data can
be streamed. You think this behavior is more consistent?
IMO it's valid to replay all the WAL data available to avoid data loss
before a promotion completes.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
