Re: make MaxBackends available in _PG_init

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(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: 2021-08-10 00:22:50
Message-ID: 77F481D5-2F4C-405E-9335-E68550375D4B@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/9/21, 1:14 PM, "Greg Sabino Mullane" <htamfids(at)gmail(dot)com> wrote:
> Giving this a review.

Thanks for your review.

> However, the more I went through this patch, the more the GetMaxBackends(0) nagged at me. The vast majority of the calls are with "0". I'd argue for just having no arguments at all, which removes a bit of code and actually makes things like this easier to read:

I agree. The argument is nonzero in less than half of the calls to
GetMaxBackends(), and I'm not sure it adds a whole lot of value in the
first place. I removed the argument in v3.

>> + * This must be called after modules have had the change to alter GUCs in
>> + * shared_preload_libraries, and before shared memory size is determined.
> s/change/chance/;

I fixed this in v3.

>> +void
>> +SetMaxBackends(int max_backends)
>> +{
>> + if (MaxBackendsInitialized)
>> + elog(ERROR, "MaxBackends already initialized");
>
> Is this going to get tripped by a call from restore_backend_variables?

I ran 'make check-world' with EXEC_BACKEND with no problems, so I
don't think so.

Nathan

Attachment Content-Type Size
v3-0001-Disallow-external-access-to-MaxBackends.patch application/octet-stream 29.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-08-10 00:57:31 Re: Another regexp performance improvement: skip useless paren-captures
Previous Message Mark Dilger 2021-08-10 00:18:27 Re: Another regexp performance improvement: skip useless paren-captures