From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve handling of parameter differences in physical replication |
Date: | 2020-02-28 07:49:08 |
Message-ID: | 5c2e1f12-2775-6e69-c1c8-46c759417b66@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | ahsan hadi | 2020-02-28 07:49:23 | Re: more ALTER .. DEPENDS ON EXTENSION fixes |
Previous Message | Michael Paquier | 2020-02-28 07:45:47 | Re: Improve handling of parameter differences in physical replication |