_delay *
pg_prng_double(_global_prng_state) +
0.5));
On Wed, Apr 10, 2024 at 9:43 AM Robert Haas wrote:
> On Wed, Apr 10, 2024 at 12:40 PM Parag Paul wrote:
> > The reason why this could be a problem is a flaw in the RNG with the
> enlarged Hamming belt.
> > I attached an
hi Robert,
We are using xoroshiro128 and not moved to the next state of art.
We did see a lot of low values as put in my last message.
-Parag
On Wed, Apr 10, 2024 at 9:37 AM Robert Haas wrote:
> On Wed, Apr 10, 2024 at 12:02 PM Tom Lane wrote:
> > As I said to Parag, I see exactly no reason to
hi Tom,
First of all thanks for you response. I did not misread it. The 0.5 is
added to the result of the multiplication which then uses C integer
casting, which does not round off, but just drops the decimal portion.
status->cur_delay += (int) (status->cur_delay *
Thank you Robert.
I am in the process of patching this.
-Parag
On Wed, Apr 10, 2024 at 7:43 AM Robert Haas wrote:
> On Tue, Apr 9, 2024 at 5:05 PM Andres Freund wrote:
> > ISTM that the fix here is to not use a spinlock for whatever the
> contention is
> > on, rather than improve the RNG.
>
>
Andres Freund wrote:
> Hi,
>
> On 2024-04-08 22:52:09 -0700, Parag Paul wrote:
> > We have an interesting problem, where PG went to PANIC due to stuck
> > spinlock case.
> > On careful analysis and hours of trying to reproduce this(something that
> > showed up i
hi all,
We have an interesting problem, where PG went to PANIC due to stuck
spinlock case.
On careful analysis and hours of trying to reproduce this(something that
showed up in production after almost 2 weeks of stress run), I did some
statistical analysis on the RNG generator that PG uses to
