| From: | Sergei Kornilov <sk(at)zsrv(dot)org> | 
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Atsushi Torikoshi <atorik(at)gmail(dot)com> | 
| Cc: | Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: replay pause vs. standby promotion | 
| Date: | 2020-03-25 10:42:56 | 
| Message-ID: | 8496531585130947@vla1-2bebf6b1c06e.qloud-c.yandex.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hi
>>  Could we add a few words in func.sgml to clarify the behavior? Especially for users from my example above. Something like:
>>
>>>  If a promotion is triggered while recovery is paused, the paused state ends, replay of any WAL immediately available in 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...
regards, Sergei
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guancheng Luo | 2020-03-25 10:43:43 | [PATCH] Check operator when creating unique index on partition table | 
| Previous Message | Richard Guo | 2020-03-25 10:36:17 | Re: weird hash plan cost, starting with pg10 |