From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Parag Paul <parag(dot)paul(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Issue with the PRNG used by Postgres |
Date: | 2024-04-10 15:09:55 |
Message-ID: | 4032321.1712761795@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm not convinced that we should try to improve the RNG, but surely we
> need to put parentheses around pg_prng_double(&pg_global_prng_state) +
> 0.5. IIUC, the current logic is making us multiply the spin delay by a
> value between 0 and 1 when what was intended was that it should be
> multiplied by a value between 0.5 and 1.5.
No, I think you are misreading it, because the assignment is += not =.
The present coding is
/* increase delay by a random fraction between 1X and 2X */
status->cur_delay += (int) (status->cur_delay *
pg_prng_double(&pg_global_prng_state) + 0.5);
which looks fine to me. The +0.5 is so that the conversion to integer
rounds rather than truncating.
In any case, I concur with Andres: if this behavior is anywhere near
critical then the right fix is to not be using spinlocks.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kartyshov Ivan | 2024-04-10 15:12:00 | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Previous Message | jian he | 2024-04-10 15:03:30 | Re: Can't find not null constraint, but \d+ shows that |