From: | "Wang, Shenhao" <wangsh(dot)fnst(at)cn(dot)fujitsu(dot)com> |
---|---|
To: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | make MaxBackends available in _PG_init |
Date: | 2020-09-21 03:43:41 |
Message-ID: | 4f20d57b2aeb447b8eb1495319940c5f@G08CNEXMBPEKD06.g08.fujitsu.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Hackers:
I find the value in function _PG_init, the value of MaxBackends is 0.
In source, I find that the postmaster will first load library, and then calculate the value of MaxBackends.
In the old version, the MaxBackends was calculated by:
MaxBackends = MaxConnections + autovacuum_max_workers + 1 +
GetNumShmemAttachedBgworkers();
Because any extension can register workers which will affect the return value of GetNumShmemAttachedBgworkers.
InitializeMaxBackends must be called after shared_preload_libraries. This is also mentioned in comments.
Now, function GetNumShmemAttachedBgworkers was deleted and replaced by guc max_worker_processes,
so if we changed the calling order like:
Step1: calling InitializeMaxBackends.
Step2: calling process_shared_preload_libraries
In this order extension can get the correct value of MaxBackends in _PG_init.
Any thoughts?
Regards
Attachment | Content-Type | Size |
---|---|---|
0001-Make-MaxBackends-available-in-_PG_init.patch | application/octet-stream | 2.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2020-09-21 03:44:30 | Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away |
Previous Message | Andy Fan | 2020-09-21 03:41:09 | Re: Dynamic gathering the values for seq_page_cost/xxx_cost |