Re: replay pause vs. standby promotion - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: replay pause vs. standby promotion
Date
Msg-id 8496531585130947@vla1-2bebf6b1c06e.qloud-c.yandex.net
Whole thread Raw
In response to Re: replay pause vs. standby promotion  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: replay pause vs. standby promotion  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
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,
butignore walreceiver also seems strange for my DBA hat...
 

regards, Sergei



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: weird hash plan cost, starting with pg10
Next
From: Guancheng Luo
Date:
Subject: [PATCH] Check operator when creating unique index on partition table