On Tue, Nov 26, 2024 at 11:36 AM Tom Lane wrote:
> I think the idea was that this mechanism is equivalent to an EMFILE
> limit. But if you feel a need to make a distinction, this seems fine:
I think we should never, ever confuse an error return from a system
call with any other kind of problem t
Hi,
On 2024-11-26 12:26:51 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-11-26 11:35:56 -0500, Tom Lane wrote:
> >> You should probably check all of 3d475515a, because I think
> >> I applied the same idea in more than one place.
>
> > Yea, there's another equivalent message for kque
Hi,
On 2024-11-26 11:35:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think it's rather confusing to claim that epoll_create1() failed when we
> > didn't even call it.
> > Why are we misattributing the failure to a system call that we didn't make?
>
> I think the idea was that this mec
Andres Freund writes:
> On 2024-11-26 11:35:56 -0500, Tom Lane wrote:
>> You should probably check all of 3d475515a, because I think
>> I applied the same idea in more than one place.
> Yea, there's another equivalent message for kqueue a few lines below.
You should remove the "treat this..." co
Andres Freund writes:
> I think it's rather confusing to claim that epoll_create1() failed when we
> didn't even call it.
> Why are we misattributing the failure to a system call that we didn't make?
I think the idea was that this mechanism is equivalent to an EMFILE
limit. But if you feel a nee
Hi,
I ran something which triggered the error in $subject. Except that it turns
out that
a) epoll_create1() was not being called
b) we didn't actually hit EMFILE or even max_safe_fds
The reason for the failure is that we have:
if (!AcquireExternalFD())
{
/* treat t
