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

From Alvaro Herrera
Subject Re: pg_usleep for multisecond delays
Date
Msg-id 20230210083026.uq25mmp34q6qznvg@alvherre.pgsql
Whole thread Raw
In response to pg_usleep for multisecond delays  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: pg_usleep for multisecond delays
List pgsql-hackers
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 more widely.  I attached a patch for the
> former approach.  I don't have a strong opinion, but I do think it's worth
> improving readability a bit here.

Hmm, it seems about half the patch would go away if you were to add a
PostAuthDelaySleep() function.

> @@ -2976,7 +2976,7 @@ _bt_pendingfsm_finalize(Relation rel, BTVacState *vstate)
>       * never be effective without some other backend concurrently consuming an
>       * XID.
>       */
> -    pg_usleep(5000000L);
> +    pg_ssleep(5);

Maybe for these cases where a WaitLatch is not desired, it'd be simpler
to do pg_usleep (5L * 1000 * 1000);

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"I am amazed at [the pgsql-sql] mailing list for the wonderful support, and
lack of hesitasion in answering a lost soul's question, I just wished the rest
of the mailing list could be like this."                               (Fotis)
               (http://archives.postgresql.org/pgsql-sql/2006-06/msg00265.php)



pgsql-hackers by date:

Previous
From: Richard Guo
Date:
Subject: Re: Inconsistent nullingrels due to oversight in deconstruct_distribute_oj_quals
Next
From: Jelte Fennema
Date:
Subject: Re: run pgindent on a regular basis / scripted manner