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-24 15:17:58 |
Message-ID: | 796401585060307@vla3-bebe75876e15.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
> I pushed the latest version of the patch. If you have further opinion
> about immediate promotion, let's keep discussing that!
Thank you!
Honestly, I forgot that the promotion is documented in high-availability.sgml as:
> Before failover, any WAL immediately available in the archive or in pg_wal will be
> restored, but no attempt is made to connect to the master.
I mistakenly thought that promote should be "immediately"...
> If a promotion is triggered while recovery is paused, the paused state ends and a promotion continues.
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.
regards, Sergei
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-03-24 15:26:23 | Re: Creating foreign key on partitioned table is too slow |
Previous Message | Tom Lane | 2020-03-24 15:09:46 | Re: documentation pdf build fail (HEAD) |