Re: Improve handling of parameter differences in physical replication
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-28T07:49:08Z
Lists: pgsql-hackers
On 2020-02-28 08:45, Michael Paquier wrote: > On Thu, Feb 27, 2020 at 02:37:24PM +0100, Peter Eisentraut wrote: >> On 2020-02-27 11:13, Fujii Masao wrote: >>>> Btw., I think the current setup is slightly buggy. The >> MaxBackends value that is used to size shared memory is computed as >> MaxConnections + autovacuum_max_workers + 1 + max_worker_processes + >> max_wal_senders, but we don't track autovacuum_max_workers in WAL. >>> Maybe this is because autovacuum doesn't work during recovery? >> >> Autovacuum on the primary can use locks or xids, and so it's possible that >> the standby when processing WAL encounters more of those than it has locally >> allocated shared memory to handle. > > Putting aside your patch because that sounds like a separate issue.. > Doesn't this mean that autovacuum_max_workers should be added to the > control file, that we need to record in WAL any updates done to it and > that CheckRequiredParameterValues() is wrong? That would be a direct fix, yes. Perhaps it might be better to track the combined MaxBackends instead, however. -- Peter Eisentraut 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