From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, hlinnaka(at)iki(dot)fi, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Race conditions in 019_replslot_limit.pl |
Date: | 2022-02-17 03:46:26 |
Message-ID: | 20220217034626.djxcwzuynpiyvnpd@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-02-16 22:11:30 -0500, Tom Lane wrote:
> So (a) it broke around 48 hours ago, which is already a useful
> bit of info
Indeed. 2f6501fa3c54bbe4568e3bcccd9a60d26a46b5ee seems like the obvious commit
to blame.
We document before_shmem_exit hooks as
/*
* Call before_shmem_exit callbacks.
*
* These should be things that need most of the system to still be up and
* working, such as cleanup of temp relations, which requires catalog
* access; or things that need to be completed because later cleanup steps
* depend on them, such as releasing lwlocks.
*/
and several before_shmem_exit callbacks use lwlocks.
But right now I'm not seeing what prevents us from throwing a FATAL error
while holding an lwlock?
> , and (b) your animals seem far more susceptible than
> anyone else's. Why do you suppose that is?
Flaviventris, serinus use the newest snapshot of gcc available in debian, one
with -O0, the other with O3.
desmoxytes, idiacanthus, komodoensis all have JIT forced for every query.
They all run on the same host - looking at stats it doesn't look crazily
overcommitted or such. But it might have more scheduler variance than most?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-17 03:58:19 | Re: Race conditions in 019_replslot_limit.pl |
Previous Message | Peter Geoghegan | 2022-02-17 03:43:09 | Re: Nonrandom scanned_pages distorts pg_class.reltuples set by VACUUM |