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 d
On 18/03/2025 01:08, Jelte Fennema-Nio wrote:
On Mon Feb 24, 2025 at 12:01 PM CET, Jelte Fennema-Nio wrote:
Right after pressing send I realized I could remove two more useless
lines...
Rebased patchset attached (trivial conflict against pg_noreturn
changes).
v7-0001-Adds-a-helper-for-places
On Mon Feb 24, 2025 at 12:01 PM CET, Jelte Fennema-Nio wrote:
Right after pressing send I realized I could remove two more useless
lines...
Rebased patchset attached (trivial conflict against pg_noreturn
changes).
From 249ebbac1b6c01b99795cfe9b0201ab7ee6bacfa Mon Sep 17 00:00:00 2001
From: Jel
On Mon Feb 24, 2025 at 11:58 AM CET, Jelte Fennema-Nio wrote:
Ughh, a compiler warning snuck on windows during some of my final
refactoring. Fixed now.
Right after pressing send I realized I could remove two more useless
lines...
From ec72e05e87c73dee3de73f9a6586e8e8db2d919e Mon Sep 17 00:00:0
On Mon Feb 24, 2025 at 10:56 AM CET, Jelte Fennema-Nio wrote:
Great! Attached are the updated other patches, I think I addressed all
feedback.
Ughh, a compiler warning snuck on windows during some of my final
refactoring. Fixed now.
From ec72e05e87c73dee3de73f9a6586e8e8db2d919e Mon Sep 17 00:00
On Thu Feb 20, 2025 at 1:37 AM CET, Andres Freund wrote:
I've pushed this, with one trivial modification: I added %m to the error
message in case setrlimit() fails. That's really unlikely to ever happen, but
...
Great! Attached are the updated other patches, I think I addressed all
feedback.
Fr
Hi,
On 2025-02-17 21:25:33 +0100, Jelte Fennema-Nio wrote:
> On Mon, 17 Feb 2025 at 18:24, Andres Freund wrote:
> > Why not do this only in the if (rlim.rlim_cur < nclients + 3) case?
>
> Done, I also changed it to not bump to rlim_max, but only to nclients
> + 3. The rest of the patches I'll up
On Mon, 17 Feb 2025 at 18:24, Andres Freund wrote:
> Why not do this only in the if (rlim.rlim_cur < nclients + 3) case?
Done, I also changed it to not bump to rlim_max, but only to nclients
+ 3. The rest of the patches I'll update later. But response below.
> I think it might be better to have
Andres Freund writes:
> On 2025-02-12 22:52:52 +0100, Jelte Fennema-Nio wrote:
>> +/*
>> + * Bump the soft limit to the hard limit to not
>> run into low
>> + * file limits.
>> + */
>>
Hi,
Thanks for these patches!
On 2025-02-12 22:52:52 +0100, Jelte Fennema-Nio wrote:
> From 8e964db585989734a5f6c1449ffb4c62e1190a6a Mon Sep 17 00:00:00 2001
> From: Jelte Fennema-Nio
> Date: Tue, 11 Feb 2025 22:04:44 +0100
> Subject: [PATCH v2 1/3] Bump pgbench soft open file limit (RLIMIT_NOFI
On Tue, 11 Feb 2025 at 22:18, Tom Lane wrote:
>
> Andres Freund writes:
> > My suggestion would be to redefine max_files_per_process as the number of
> > files we try to be able to open in backends. I.e. set_max_safe_fds() would
> > first count the number of already open fds (since those will lar
Hi,
On 2025-02-11 17:55:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> > So the issue would actually be that we're currently doing set_max_safe_fds()
> > too late, not too early :/
>
> Well, we'd rather set_max_safe_fds happen after semaphore creation,
> so that it doesn't have to be explic
Tomas Vondra writes:
> On 2/11/25 21:18, Tom Lane wrote:
>> I think what we actually would like to know is how often we have to
>> close an open FD in order to make room to open a different file.
>> Maybe that's the same thing you mean by "cache miss", but it doesn't
>> seem like quite the right t
Andres Freund writes:
> In the current version of the AIO patchset, the creation of those io_uring
> instances does happen as part of an shmem init callback, as the io uring
> creation also sets up queues visible in shmem.
Hmm.
> So the issue would actually be that we're currently doing set_max_
On 2/11/25 22:14, Andres Freund wrote:
> Hi,
>
> On 2025-02-11 21:04:25 +0100, Tomas Vondra wrote:
>> I agree the defaults may be pretty low for current systems, but do we
>> want to get into the business of picking a value and overriding whatever
>> value is set by the sysadmin? I don't think
On 2/11/25 21:18, Tom Lane wrote:
> Tomas Vondra writes:
>> I did run into bottlenecks due to "too few file descriptors" during a
>> recent experiments with partitioning, which made it pretty trivial to
>> get into a situation when we start trashing the VfdCache. I have a
>> half-written draft
Hi,
On 2025-02-11 16:18:37 -0500, Tom Lane wrote:
> Andres Freund writes:
> > And when using something like io_uring for AIO, it'd allow to
> > max_files_per_process in addition to the files requires for the io_uring
> > instances.
>
> Not following? Surely we'd not be configuring that so early
Andres Freund writes:
> My suggestion would be to redefine max_files_per_process as the number of
> files we try to be able to open in backends. I.e. set_max_safe_fds() would
> first count the number of already open fds (since those will largely be
> inherited by child processes) and then check if
Hi,
On 2025-02-11 21:04:25 +0100, Tomas Vondra wrote:
> I agree the defaults may be pretty low for current systems, but do we
> want to get into the business of picking a value and overriding whatever
> value is set by the sysadmin? I don't think a high hard limit should be
> seen as an implicit p
Tomas Vondra writes:
> I did run into bottlenecks due to "too few file descriptors" during a
> recent experiments with partitioning, which made it pretty trivial to
> get into a situation when we start trashing the VfdCache. I have a
> half-written draft of a blog post about that somewhere.
> But
On 2/11/25 20:20, Tom Lane wrote:
> Jelte Fennema-Nio writes:
>> The default open file limit of 1024 is extremely low, given modern
>> resources and kernel architectures. The reason that this hasn't changed
>> change is because doing so would break legacy programs that use the
>> select(2) system
Andres Freund writes:
> I don't see a downside to just increasing the soft limit for
> pgbench.
Agreed, that end of the patch seems relatively harmless.
regards, tom lane
I wrote:
> Maybe a sanity limit on how high we'll try to raise the ulimit
> would help.
Oh, I'd forgotten that we already have one: max_files_per_process.
Since that's only 1000 by default, this patch doesn't actually have
any effect (on Linux anyway) unless the DBA raises
max_files_per_process.
Hi,
On 2025-02-11 19:52:34 +0100, Jelte Fennema-Nio wrote:
> So this starts bumping postmaster and pgbench its soft open file limit
> to the hard open file limit.
Not sure that's quite the right thing to do for postmaster. What I'd start
with is to increase the soft limit to
"already used files
Jelte Fennema-Nio writes:
> The default open file limit of 1024 is extremely low, given modern
> resources and kernel architectures. The reason that this hasn't changed
> change is because doing so would break legacy programs that use the
> select(2) system call in hard to debug ways. So instead p
Subject: [PATCH v1] Bump soft open file limit (RLIMIT_NOFILE) to hard limit on
startup
The default open file limit of 1024 is extremely low, given modern
resources and kernel architectures. The reason that this hasn't changed
change is because doing so would break legacy programs that use the
s
26 matches
Mail list logo
