On Tue, Mar 12, 2019 at 6:13 PM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Mar 11, 2019 at 8:03 PM Tom Lane wrote:
> >> While the WaitLatch alternative avoids the problem, I doubt
> >> we're ever going to remove pg_usleep entirely, so it'd be
> >> good if it had fewer sharp edges.
Robert Haas writes:
> On Tue, Mar 12, 2019 at 1:13 PM Tom Lane wrote:
>> (I'm not sure what I think about which behavior is really more
>> desirable. We can debate that if there's actually a plausible
>> choice to be made, which seems to depend on Windows.)
> Yeah, that's a fair question. My
Hi,
On March 12, 2019 10:17:19 AM PDT, Robert Haas wrote:
>On Tue, Mar 12, 2019 at 1:13 PM Tom Lane wrote:
>> (I'm not sure what I think about which behavior is really more
>> desirable. We can debate that if there's actually a plausible
>> choice to be made, which seems to depend on Windows.)
On Tue, Mar 12, 2019 at 1:13 PM Tom Lane wrote:
> (I'm not sure what I think about which behavior is really more
> desirable. We can debate that if there's actually a plausible
> choice to be made, which seems to depend on Windows.)
Yeah, that's a fair question. My motivation for asking was
Robert Haas writes:
> On Mon, Mar 11, 2019 at 8:03 PM Tom Lane wrote:
>> While the WaitLatch alternative avoids the problem, I doubt
>> we're ever going to remove pg_usleep entirely, so it'd be
>> good if it had fewer sharp edges. nanosleep() has the
>> same behavior as Windows, ie, the sleep
On Mon, Mar 11, 2019 at 8:03 PM Tom Lane wrote:
> While the WaitLatch alternative avoids the problem, I doubt
> we're ever going to remove pg_usleep entirely, so it'd be
> good if it had fewer sharp edges. nanosleep() has the
> same behavior as Windows, ie, the sleep is guaranteed to be
>
In the thread about vacuum_cost_delay vs vacuum_cost_limit,
I wondered whether nanosleep(2) would provide any better
timing resolution than select(2). Some experimentation
suggests that it doesn't, but nonetheless I see a good reason
why we should consider making pg_usleep use nanosleep() if
