Re: pg_usleep for multisecond delays

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_usleep for multisecond delays
Date: 2023-02-10 08:30:26
Message-ID: 20230210083026.uq25mmp34q6qznvg@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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 —
"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)

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-02-10 09:25:44 Re: run pgindent on a regular basis / scripted manner
Previous Message Richard Guo 2023-02-10 08:27:14 Re: Inconsistent nullingrels due to oversight in deconstruct_distribute_oj_quals