From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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-11 20:46:10 |
Message-ID: | 241162.1712868370@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2024-04-11 16:11:40 -0400, Tom Lane wrote:
>> We wouldn't need to fix it, if we simply removed the NUM_DELAYS
>> limit. Whatever kicked us off the sleep doesn't matter, we might
>> as well go check the spinlock.
> I suspect we should fix it regardless of whether we keep NUM_DELAYS. We
> shouldn't increase cur_delay faster just because a lot of signals are coming
> in.
I'm unconvinced there's a problem there. Also, what would you do
about this that wouldn't involve adding kernel calls for gettimeofday?
Admittedly, if we only do that when we're about to sleep, maybe it's
not so awful; but it's still adding complexity that I'm unconvinced
is warranted.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-04-11 20:46:23 | Re: Issue with the PRNG used by Postgres |
Previous Message | Tom Lane | 2024-04-11 20:35:58 | Re: Should we add a compiler warning for large stack frames? |