Feedback-ID: ie0a040ee:Fastmail
Message-ID: <b97ccf25-687b-4fd5-ae96-32dd5e611da4@eisentraut.org>
Date: Wed, 29 Oct 2025 11:11:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on
 startup
To: Jelte Fennema-Nio <postgres@jeltef.nl>,
 Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas@vondra.me>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
References: 
 <CAGECzQQh6VSy3KG4pN1d=h9J=D1rStFCMR+t7yh_Kwj-g87aLQ@mail.gmail.com>
 <3203865.1739301613@sss.pgh.pa.us>
 <94798ef1-0f13-416a-983a-88447e434a7f@vondra.me>
 <7u7dbn6s2i6bf3hjzkbqaexj2bpoblqxwbkffbetl4rjv6dcom@s2uickjc5z53>
 <3216369.1739308717@sss.pgh.pa.us>
 <CAGECzQQqO0DKhyZtUWRKSL=WeBSYM=+gZ+dY58xQ2ZnypSONTw@mail.gmail.com>
 <lj5q3h4zxwhfusvv2azjnwva74yjwthkrrsvcxrac67f636tpi@ewtgldqjfwes>
 <CAGECzQQ1JnUim8KEFVrM+d4zfvxg=yVmzB8rLv4W5mKmnVnEuQ@mail.gmail.com>
 <4huky7iczrycvq3ptpjkkzrclsabqceu6jyppizotjafqywq5g@g4eynaqxjog5>
 <D80L44E10W12.35QIRYPTCJO4P@jeltef.nl> <D80MFYSUCCXW.2FUSI7E6R6STU@jeltef.nl>
 <D80MHNSG4EET.6MSV5G9P130F@jeltef.nl> <D8IX3P6DMLCA.2C6XZADX1MCHS@jeltef.nl>
 <9004aa84-4ea3-414f-9268-101510f41a29@iki.fi>
 <D95RE1URB4NV.1HOTIBF6OY7YD@jeltef.nl>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <D95RE1URB4NV.1HOTIBF6OY7YD@jeltef.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b97ccf25-687b-4fd5-ae96-32dd5e611da4%40eisentraut.org>
Precedence: bulk

On 13.04.25 21:30, Jelte Fennema-Nio wrote:
> On Fri Apr 4, 2025 at 7:34 PM CEST, Heikki Linnakangas wrote:
>> Let's move that 'in_restore_command' business to the caller. It's 
>> weird modularity for the function to implicitly behave differently for 
>> some callers. 
> 
> I definitely agree with the sentiment, and it was what I originally
> planned to do. But then I went for this approach anyway because commit
> 8fb13dd6ab5b explicitely moved all code except for the actual call to
> system() out of the PreRestoreCommand()/PostRestoreCommand() section
> (which is also described in the code comment).
> So I didn't move the the in_restore_command stuff to the caller, and
> improved the function comment to call out this unfortunate coupling.
>> And 'wait_event_info' should only affect pgstat reporting, not actual 
>> behavior.
> 
> Given that we need to keep the restore command stuff in this function, I
> think the only other option is to add a dedicated argument for the
> restore command stuff, like "bool is_restore_command". But that would
> require every caller, except for the restore command, to pass an
> additional "false" as an argument. To me the additionaly noise that that
> adds seems like a worse issue than the non-purity we get by
> piggy-backing on the wait_event_info argument.
> 
>> I don't feel good about the function name. How about pg_system() or 
>> something? 

This patch set is showing compiler warnings because pg_system() wasn't 
properly declared where needed.  Please provide an update that builds 
cleanly.

Also, it appears the patch for pgbench disappeared from the series.  Was 
that intentional?