| 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: | Whole Thread | Raw Message | 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 |