| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | 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-27 13:37:24 |
| Message-ID: | c46df4ab-ac96-0c3e-fb48-1670d44d1a97@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Kondratov | 2020-02-27 13:41:42 | Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line |
| Previous Message | legrand legrand | 2020-02-27 13:12:58 | Re: Using stat collector for collecting long SQL |