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-26 14:37:30 |
Message-ID: | 19108601585229516@iva1-3b1c0a1a240c.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
> 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?
We have no simple point to stop replay.
Well, except for "immediately" - just one easy stop. But I agree that this is not the best option. Simple and clear, but not best one for data when we want to replay as much as possible from archive.
> IMO it's valid to replay all the WAL data available to avoid data loss
> before a promotion completes.
But in case of still working primary (with archive_command) we choose quite random time to promote. A random time when the primary did not save the new wal segment.
or even when a temporary error of restore_command occurs? We mention just cp command in docs. I know users uses cp (e.g. from NFS) without further error handling.
regards, Sergei
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-03-26 14:40:09 | Re: Patch: to pass query string to pg_plan_query() |
Previous Message | Tom Lane | 2020-03-26 14:26:25 | Re: Resolving the python 2 -> python 3 mess |