Alvaro Herrera writes:
> On 2020-Feb-24, Tom Lane wrote:
>> Why not just drive it off max_files_per_process? On Unix, that
>> largely exists to override the ulimit setting anyway. With no
>> comparable knob on a Windows system, we might as well just say
>> that's what you set.
> That makes sens
On 2020-Feb-24, Tom Lane wrote:
> Alvaro Herrera writes:
> > Then again, that would be akin to setrlimit() on Linux. Maybe we can
> > consider that a separate GUC, in a separate patch, with a
> > platform-specific default value that just corresponds to the OS's
> > default, and the user can set
Alvaro Herrera writes:
> On 2020-Feb-24, Tom Lane wrote:
>> I don't think there's much point in telling Windows users about
>> _setmaxstdio() here.
> Yeah, telling users to _setmaxstdio() themselves is useless, because
> they can't do it; that's something *we* should do. I think the 512
> limit
On 2020-Feb-24, Tom Lane wrote:
> I wrote:
> > I thought about platform-specific messages, but it's not clear to me
> > whether our translation infrastructure will find messages that are
> > inside #ifdefs ... anyone know?
>
> Oh, but of course it does. So let's do
>
> errdetail("There
I wrote:
> Alvaro Herrera writes:
>> As for the platform dependencies, I see two main options: make the hint
>> platform-specific (i.e have #ifdef branches per platform) or make it
>> even more generic, such as "file descriptor limits".
> I thought about platform-specific messages, but it's not c
Andres Freund writes:
> On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote:
>> I suppose we do use the C runtime. There's a reference to
>> _setmaxstdio() being able to raise the limit from the default of 512 to
>> up to 8192 open files. We don't currently invoke that.
>> https://docs.microsoft.
Hi,
On 2020-02-24 16:14:53 -0300, Alvaro Herrera wrote:
> But the C runtime does:
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/file-handling?view=vs-2019
> I suppose we do use the C runtime. There's a reference to
> _setmaxstdio() being able to raise the limit from the default of 512
Alvaro Herrera writes:
> On 2020-Feb-24, Tom Lane wrote:
>> We could also consider a HINT, along the lines of "Raise the server's
>> max_files_per_process and/or \"ulimit -n\" limits." This again has
>> the ambiguity about which server, and it also seems dangerously
>> platform-specific.
> Maybe
On 2020-Feb-24, Tom Lane wrote:
> We could also consider a HINT, along the lines of "Raise the server's
> max_files_per_process and/or \"ulimit -n\" limits." This again has
> the ambiguity about which server, and it also seems dangerously
> platform-specific.
Maybe talk about "the local server"
Mark Dilger writes:
>> On Feb 20, 2020, at 8:30 PM, Tom Lane wrote:
>> This idea doesn't fix every possible problem. For instance, if you
>> have a plperlu function that wants to open a bunch of files, I don't
>> see any easy way to ensure we release VFDs to make that possible.
>> But it's sure
Hi,
On 2020-02-24 10:29:51 -0800, Mark Dilger wrote:
> > On Feb 20, 2020, at 8:30 PM, Tom Lane wrote:
> >
> > This idea doesn't fix every possible problem. For instance, if you
> > have a plperlu function that wants to open a bunch of files, I don't
> > see any easy way to ensure we release VFD
> On Feb 20, 2020, at 8:30 PM, Tom Lane wrote:
>
> This idea doesn't fix every possible problem. For instance, if you
> have a plperlu function that wants to open a bunch of files, I don't
> see any easy way to ensure we release VFDs to make that possible.
> But it's sure an improvement on th
Thomas Munro writes:
> I suppose there may be users who have set ulimit -n high enough to
> support an FDW workload that connects to very many hosts, who will now
> need to set max_files_per_process higher to avoid the new error now
> that we're doing this accounting. That doesn't seem to be a pr
On Mon, Feb 24, 2020 at 7:42 PM Thomas Munro wrote:
> On Mon, Feb 24, 2020 at 12:24 PM Tom Lane wrote:
> > On reflection, trying to make ReserveExternalFD serve two different
> > use-cases was pretty messy. Here's a version that splits it into two
> > functions. I also took the trouble to fix d
On Mon, Feb 24, 2020 at 12:24 PM Tom Lane wrote:
> On reflection, trying to make ReserveExternalFD serve two different
> use-cases was pretty messy. Here's a version that splits it into two
> functions. I also took the trouble to fix dblink.
+/*
+ * We don't want more than max_safe_fds
I wrote:
> Here's a draft patch that does it like that.
On reflection, trying to make ReserveExternalFD serve two different
use-cases was pretty messy. Here's a version that splits it into two
functions. I also took the trouble to fix dblink.
regards, tom lane
diff --gi
I wrote:
>> Clearly, we gotta do something about that too. Maybe bumping up
>> NUM_RESERVED_FDS would be a good idea, but I feel like more-honest
>> accounting for permanently-eaten FDs would be a better idea. And
>> in any case we can't suppose that there's a fixed upper limit on
>> the number o
I wrote:
> Clearly, we gotta do something about that too. Maybe bumping up
> NUM_RESERVED_FDS would be a good idea, but I feel like more-honest
> accounting for permanently-eaten FDs would be a better idea. And
> in any case we can't suppose that there's a fixed upper limit on
> the number of pos
I wrote:
> Thomas Munro writes:
>> ... like coypu, where NUM_RESERVED_FDS is
>> the only thing ensuring we have some spare fds. I don't know the
>> history but it looks like NUM_RESERVED_FDS was deliberately or
>> accidentally tuned to be just enough to be able to run the regression
>> tests (the
Thomas Munro writes:
> One thing I've been planning to do for 13 is to get rid of all the
> temporary create/destroy WaitEventSets from the main backend loops.
> My goal was cutting down on stupid system calls, but this puts a new
> spin on it. I have a patch set to do a bunch of that[1], but now
On Fri, Feb 21, 2020 at 8:56 AM Tom Lane wrote:
> I wrote:
> > It seems fairly obvious now that I look at it, but: the epoll and kqueue
> > variants of CreateWaitEventSet are both *fundamentally* unsafe, because
> > they assume that they can always get a FD when they want one, which is
> > not a p
I wrote:
> It seems fairly obvious now that I look at it, but: the epoll and kqueue
> variants of CreateWaitEventSet are both *fundamentally* unsafe, because
> they assume that they can always get a FD when they want one, which is
> not a property that we generally want backend code to have. The o
[ redirecting to -hackers ]
I wrote:
> =?utf-8?Q?R=C3=A9mi_Zara?= writes:
> Le 20 févr. 2020 à 12:15, Thomas Munro a écrit :
>>> Remi, any chance you could run gmake installcheck under
>>> contrib/postgres_fdw on that host, to see if this is repeatable? Can
>>> you tell us about the relevant li
23 matches
Mail list logo
