Subject: Re: Improve handling of parameter differences in physical replication
To: Fujii Masao <masao.fujii@oss.nttdata.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <4ad69a4c-cc9b-0dfe-0352-8b1b0cd36c7b@2ndquadrant.com>
 <27894a76-d498-f3fd-d77f-7c03140fbfe9@oss.nttdata.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Organization: 2ndQuadrant
Message-ID: <c46df4ab-ac96-0c3e-fb48-1670d44d1a97@2ndquadrant.com>
Date: Thu, 27 Feb 2020 14:37:24 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0)
 Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <27894a76-d498-f3fd-d77f-7c03140fbfe9@oss.nttdata.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services