Re: pg_usleep for multisecond delays - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: pg_usleep for multisecond delays
Date
Msg-id 20230210200037.GA891016@nathanxps13
Whole thread Raw
In response to Re: pg_usleep for multisecond delays  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: pg_usleep for multisecond delays  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 <robertmhaas@gmail.com> 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 for
>>> interrupts etc.
>> 
>> Resetting the latch seems not very friendly for general-purpose use
>> ... although I guess we could set it again on the way out.
>> 
>> BTW, we have an existing pg_sleep() function that deals with all
>> of this except re-setting the latch.
> 
> That seems workable.  I think it might also need to accept a function
> pointer for custom interrupt checking (e.g., archiver code should use
> HandlePgArchInterrupts()).  I'll put something together if that sounds
> alright.

Here is a work-in-progress patch.  I quickly scanned through my previous
patch and applied this new function everywhere it seemed safe to use (which
unfortunately is rather limited).

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: appendBinaryStringInfo stuff
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] Compression dictionaries for JSONB