On Mon, Sep 21, 2020 at 9:14 AM Wang, Shenhao <wangsh.f...@cn.fujitsu.com> wrote: > > 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 >
Yes, the GetNumShmemAttachedBgworkers() was removed by commit # dfbba2c86cc8f09cf3ffca3d305b4ce54a7fb49a. ASAICS, changing the order of InitializeMaxBackends() and process_shared_preload_libraries() has no problem, as InitializeMaxBackends() doesn't calculate the MaxBackends based on bgworker infra code, it does calculate based on GUCs. Having said that, I'm not quite sure whether any of the bgworker registration code, for that matter process_shared_preload_libraries() code path will somewhere use MaxBackends? > > In this order extension can get the correct value of MaxBackends in _PG_init. > Is there any specific use case that any of the _PG_init will use MaxBackends? I think the InitializeMaxBackends() function comments still say as shown below. * This must be called after modules have had the chance to register background * workers in shared_preload_libraries, and before shared memory size is * determined. What happens with your patch in EXEC_BACKEND cases? (On linux EXEC_BACKEND (include/pg_config_manual.h) can be enabled for testing purposes). With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
