Re: Improve handling of parameter differences in physical replication
Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-09T08:11:56Z
Lists: pgsql-hackers
On Sat, 29 Feb 2020 at 06:39, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > > 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. I think after recovery is paused users will be better to restart the server rather than resume the recovery. I agree with this idea but I'm slightly concerned that users might not realize that recovery is paused until they look at that line in server log or at pg_stat_replication because the standby server is still functional. So I think we can periodically send WARNING to inform user that we're still waiting for parameter change and restart. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Pause recovery for insufficient parameter settings
- 15251c0a60be 14.0 landed
-
Replace a macro by a function
- b5acf10cfc63 14.0 landed
-
Improve handling of parameter differences in physical replication
- 246f136e76ec 13.0 landed
-
Prefer standby promotion over recovery pause.
- 496ee647ecd2 13.0 cited