From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Improve handling of parameter differences in physical replication
Date: Fri, 28 Feb 2020 12:33:31 -0300
Message-ID: <20200228153331.GA31634@alvherre.pgsql> (raw)
In-Reply-To: <4ad69a4c-cc9b-0dfe-0352-8b1b0cd36c7b@2ndquadrant.com>
On 2020-Feb-27, Peter Eisentraut wrote:
> So this patch relaxes this a bit. Upon receipt of
> XLOG_PARAMETER_CHANGE, we still check the settings but only issue a
> warning and set a global flag if there is a problem. Then when we
> actually hit the resource issue and the flag was set, we issue another
> warning message with relevant information. Additionally, at that
> point we pause recovery, so a hot standby remains usable.
Hmm, so what is the actual end-user behavior? As I read the code, we
first send the WARNING, then pause recovery until the user resumes
replication; at that point we raise the original error. Presumably, at
that point the startup process terminates and is relaunched, and replay
continues normally. Is that it?
I think if the startup process terminates because of the original error,
after it is unpaused, postmaster will get that as a signal to do a
crash-recovery cycle, closing all existing connections. Is that right?
If so, it would be worth improving that (possibly by adding a
sigsetjmp() block) to avoid the disruption.
Thanks,
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@2ndquadrant.com, peter.eisentraut@2ndquadrant.com
Subject: Re: Improve handling of parameter differences in physical replication
In-Reply-To: <20200228153331.GA31634@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox