At Wed, 26 Jul 2023 16:41:25 -0700, Nathan Bossart
wrote in
> On Mon, Mar 13, 2023 at 02:16:31PM -0700, Nathan Bossart wrote:
> I started on the former approach (work-in-progress patch attached), but I
> figured I'd ask whether folks are alright with this before I spend more
> time on it. Many
On Mon, Mar 13, 2023 at 02:16:31PM -0700, Nathan Bossart wrote:
> At the moment, I'm thinking about either removing the check_interrupts
> function pointer argument altogether or making it optional for code paths
> where we might not want any interrupt handling to run. In the former
> approach,
On Mon, Jul 10, 2023 at 10:12:36AM +0200, Daniel Gustafsson wrote:
> Have you had any chance to revisit this such that there is a new patch to
> review, or should it be returned/moved for now?
Not yet. I moved it to the next commitfest.
--
Nathan Bossart
Amazon Web Services:
> On 4 Apr 2023, at 05:31, Nathan Bossart wrote:
>
> On Mon, Apr 03, 2023 at 04:33:27PM -0400, Gregory Stark (as CFM) wrote:
>> Is this still a WIP? Is it targeting this release? There are only a
>> few days left before the feature freeze. I'm guessing it should just
>> move to the next CF for
On Mon, Apr 03, 2023 at 04:33:27PM -0400, Gregory Stark (as CFM) wrote:
> Is this still a WIP? Is it targeting this release? There are only a
> few days left before the feature freeze. I'm guessing it should just
> move to the next CF for the next release?
I moved it to the next commitfest and
On Mon, 13 Mar 2023 at 17:17, Nathan Bossart wrote:
>
> On Fri, Mar 10, 2023 at 12:28:28PM -0500, Tom Lane wrote:
> > A quick grep for pg_usleep with large intervals finds rather more
> > than you touched:
> >
> > [...]
> >
> > Did you have reasons for excluding the rest of these?
>
> I'm still
On Fri, Mar 10, 2023 at 12:28:28PM -0500, Tom Lane wrote:
> A quick grep for pg_usleep with large intervals finds rather more
> than you touched:
>
> [...]
>
> Did you have reasons for excluding the rest of these?
I'm still looking into each of these, but my main concerns were 1) ensuring
latch
Nathan Bossart writes:
> On Fri, Feb 10, 2023 at 10:51:20AM -0800, Nathan Bossart wrote:
>> On Fri, Feb 10, 2023 at 10:18:34AM -0500, Tom Lane wrote:
>>> BTW, we have an existing pg_sleep() function that deals with all
>>> of this except re-setting the latch.
> Here is a work-in-progress patch.
On Fri, Feb 10, 2023 at 10:51:20AM -0800, Nathan Bossart wrote:
> On Fri, Feb 10, 2023 at 10:18:34AM -0500, Tom Lane wrote:
>> Robert Haas writes:
>>> I wonder if we should have a wrapper around WaitLatch() that documents
>>> that if the latch is set before the time expires, it will reset the
>>>
On Fri, Feb 10, 2023 at 10:18:34AM -0500, Tom Lane wrote:
> Robert Haas writes:
>> I wonder if we should have a wrapper around WaitLatch() that documents
>> that if the latch is set before the time expires, it will reset the
>> latch and try again to wait for the remaining time, after checking
Robert Haas writes:
> I somehow feel that we should be trying to get rid of cases where
> WaitLatch is not desired.
+1
> I wonder if we should have a wrapper around WaitLatch() that documents
> that if the latch is set before the time expires, it will reset the
> latch and try again to wait for
On Fri, Feb 10, 2023 at 3:30 AM Alvaro Herrera wrote:
> Maybe for these cases where a WaitLatch is not desired, it'd be simpler
> to do pg_usleep (5L * 1000 * 1000);
I somehow feel that we should be trying to get rid of cases where
WaitLatch is not desired.
That's probably overly simplistic -
On 2023-Feb-09, Nathan Bossart wrote:
> I just found myself carefully counting the zeros in a call to pg_usleep().
> Besides getting my eyes checked, perhaps there should be a wrapper called
> pg_ssleep() than can be used for multisecond sleeps. Or maybe the
> USECS_PER_SEC macro should be used
On Thu, Feb 09, 2023 at 02:51:14PM -0800, Nathan Bossart wrote:
> Hm... We might be able to use WaitLatch() for some of these.
Perhaps less than you think as a bit of work has been done in the last
few years to reduce the gap and make such code paths more responsive,
still I would not be
At Thu, 9 Feb 2023 14:51:14 -0800, Nathan Bossart
wrote in
> On Thu, Feb 09, 2023 at 01:30:27PM -0800, Andres Freund wrote:
> > So I'm not sure it's the right direction to make pg_usleep() easier to
> > use...
> Hm... We might be able to use WaitLatch() for some of these.
And I think we are
On Thu, Feb 09, 2023 at 01:30:27PM -0800, Andres Freund wrote:
> On 2023-02-09 12:59:29 -0800, Nathan Bossart wrote:
>> I just found myself carefully counting the zeros in a call to pg_usleep().
>> Besides getting my eyes checked, perhaps there should be a wrapper called
>> pg_ssleep() than can be
Hi,
On 2023-02-09 12:59:29 -0800, Nathan Bossart wrote:
> I just found myself carefully counting the zeros in a call to pg_usleep().
> Besides getting my eyes checked, perhaps there should be a wrapper called
> pg_ssleep() than can be used for multisecond sleeps. Or maybe the
> USECS_PER_SEC
I just found myself carefully counting the zeros in a call to pg_usleep().
Besides getting my eyes checked, perhaps there should be a wrapper called
pg_ssleep() than can be used for multisecond sleeps. Or maybe the
USECS_PER_SEC macro should be used more widely. I attached a patch for the
former
18 matches
Mail list logo
