Re: make MaxBackends available in _PG_init - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: make MaxBackends available in _PG_init
Date
Msg-id 77F481D5-2F4C-405E-9335-E68550375D4B@amazon.com
Whole thread Raw
In response to Re: make MaxBackends available in _PG_init  (Greg Sabino Mullane <htamfids@gmail.com>)
Responses Re: make MaxBackends available in _PG_init
List pgsql-hackers
On 8/9/21, 1:14 PM, "Greg Sabino Mullane" <htamfids@gmail.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
callsare with "0". I'd argue for just having no arguments at all, which removes a bit of code and actually makes things
likethis 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

pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Another regexp performance improvement: skip useless paren-captures
Next
From: Tom Lane
Date:
Subject: Re: Another regexp performance improvement: skip useless paren-captures