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

From Sergei Kornilov
Subject Re: replay pause vs. standby promotion
Date
Msg-id 19108601585229516@iva1-3b1c0a1a240c.qloud-c.yandex.net
Whole thread Raw
In response to Re: replay pause vs. standby promotion  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List 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,
butnot 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
theprimary 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Resolving the python 2 -> python 3 mess
Next
From: Julien Rouhaud
Date:
Subject: Re: Patch: to pass query string to pg_plan_query()