Re: make MaxBackends available in _PG_init

From: "Anton A(dot) Melnikov" <aamelnikov(at)inbox(dot)ru>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "wangsh(dot)fnst(at)fujitsu(dot)com" <wangsh(dot)fnst(at)fujitsu(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: make MaxBackends available in _PG_init
Date: 2022-05-06 06:35:05
Message-ID: 329cad2e-b4d6-9199-16a7-f6d463d8268b@inbox.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello!

On 19.04.2022 18:46, Nathan Bossart wrote:
> Okay, I did it this way in v5.
>

Recently i ran into a problem that it would be preferable in our
extended pg_stat_statements to use MaxBackEnds in _PG_Init() but it's
equal to zero here.
And i was very happy to find this patch and this thread. It was not
only very interesting and informative for me but also solves the current
problem. Patch is applied cleanly on current master. Tests under Linux
and Windows were successful.
I've tried this patch with our extended pg_stat_statements and checked
that MaxBackends has the correct value during extra shmem allocating.
Thanks a lot!

+1 for this patch.

I have a little doubt about the comment in postmaster.c: "Now that
loadable modules have had their chance to alter any GUCs". Perhaps this
comment is too general. Not sure that it is possible to change any
arbitrary GUC here.
And maybe not bad to add Assert(size > 0) in RequestAddinShmemSpace() to
see that the size calculation in contrib was wrong.

With best regards,

--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message wangw.fnst@fujitsu.com 2022-05-06 07:11:56 RE: Logical replication timeout problem
Previous Message Tom Lane 2022-05-06 06:00:57 Re: strange slow query - lost lot of time somewhere