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 |
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 |