| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Parag Paul <parag(dot)paul(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Issue with the PRNG used by Postgres |
| Date: | 2024-04-10 16:43:00 |
| Message-ID: | CA+TgmoZi_dDDs5y_uXoyq33uFyiaHO7bo-_8GK_qyjHuBi+RfA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 10, 2024 at 12:40 PM Parag Paul <parag(dot)paul(at)gmail(dot)com> wrote:
> The reason why this could be a problem is a flaw in the RNG with the enlarged Hamming belt.
> I attached an image here, with the RNG outputs from 2 backends. I ran our code for weeks, and collected ther
> values generated by the RNG over many backends. The one in Green (say backend id 600), stopped flapping values and
> only produced low (near 0 ) values for half an hour, whereas the Blue(say backend 700), kept generating good values and had
> a range between [0-1)
> During this period, the backed 600 suffered and ended up with spinlock stuck condition.
This is a very vague description of a test procedure. If you provide a
reproducible series of steps that causes a stuck spinlock, I imagine
everyone will be on board with doing something about it. But this
graph is not going to convince anyone of anything.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Parag Paul | 2024-04-10 16:48:42 | Re: Issue with the PRNG used by Postgres |
| Previous Message | Parag Paul | 2024-04-10 16:42:03 | Re: Issue with the PRNG used by Postgres |