public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
To: Heikki Linnakangas <[email protected]>
To: Andres Freund <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
Date: Wed, 29 Oct 2025 11:11:51 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAGECzQQh6VSy3KG4pN1d=h9J=D1rStFCMR+t7yh_Kwj-g87aLQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<7u7dbn6s2i6bf3hjzkbqaexj2bpoblqxwbkffbetl4rjv6dcom@s2uickjc5z53>
<[email protected]>
<CAGECzQQqO0DKhyZtUWRKSL=WeBSYM=+gZ+dY58xQ2ZnypSONTw@mail.gmail.com>
<lj5q3h4zxwhfusvv2azjnwva74yjwthkrrsvcxrac67f636tpi@ewtgldqjfwes>
<CAGECzQQ1JnUim8KEFVrM+d4zfvxg=yVmzB8rLv4W5mKmnVnEuQ@mail.gmail.com>
<4huky7iczrycvq3ptpjkkzrclsabqceu6jyppizotjafqywq5g@g4eynaqxjog5>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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?
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Bump soft open file limit (RLIMIT_NOFILE) to hard limit on startup
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox