Re: make MaxBackends available in _PG_init
Nathan Bossart <bossartn@amazon.com>
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-02T18:18:25Z
Lists: pgsql-hackers
Attachments
- v1-0001-Calculate-MaxBackends-earlier-in-PostmasterMain.patch (application/octet-stream) patch v1-0001
On 9/21/20, 4:52 AM, "Bharath Rupireddy" <bharath.rupireddyforpostgres@gmail.com> wrote: > On Mon, Sep 21, 2020 at 9:14 AM Wang, Shenhao > <wangsh.fnst@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 just encountered the same thing, so I am bumping this thread. I was trying to use MaxBackends in a call to RequestAddinShmemSpace() in a _PG_init() function for a module, but since MaxBackends is not yet initialized, you essentially need to open-code InitializeMaxBackends() instead. I think the comments about needing to register background workers before initializing MaxBackends have been incorrect since the addition of max_worker_processes in v9.4 (6bc8ef0b). Furthermore, I think the suggested reordering is a good idea because it is not obvious that MaxBackends will be uninitialized in _PG_init(), and use-cases like the RequestAddinShmemSpace() one are not guaranteed to fail when MaxBackends is used incorrectly (presumably due to the 100 KB buffer added in CreateSharedMemoryAndSemaphores()). I've attached a new version of the proposed patch with some slight adjustments and an attempt at a commit message. Nathan
Commits
-
Add a new shmem_request_hook hook.
- 4f2400cb3f10 15.0 landed
-
Remove non-functional code for unloading loadable modules.
- ab02d702ef08 15.0 landed
-
Fix misleading comments about background worker registration.
- 701d918a426b 15.0 landed
-
Revert the addition of GetMaxBackends() and related stuff.
- 7fc0e7de9fb8 15.0 landed
-
Fix typo in multixact.c
- 0147fc7c8c92 15.0 landed
-
Reduce more the number of calls to GetMaxBackends()
- 4567596316d1 15.0 landed
-
Remove MaxBackends variable in favor of GetMaxBackends() function.
- aa64f23b0292 15.0 landed
-
Fix comments about bgworker registration before MaxBackends initialization
- 5ecd0183fb6a 15.0 landed
-
Fix bogus assertion in BootstrapModeMain().
- e12694523e7e 15.0 cited
-
Make sure MaxBackends is always set
- dfbba2c86cc8 9.3.0 cited