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 |
Thread: | |
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 — 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)
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 |