Re: Race conditions in 019_replslot_limit.pl
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, hlinnaka@iki.fi, pgsql-hackers@postgresql.org
Date: 2022-02-16T17:26:25Z
Lists: pgsql-hackers
Hi, On 2022-02-16 18:04:14 +0900, Masahiko Sawada wrote: > On Wed, Feb 16, 2022 at 3:22 PM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: > > > > At Wed, 16 Feb 2022 14:58:23 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in > > > Or it's possible that the process took a time to clean up the > > > temporary replication slot? > > > > Checkpointer may take ReplicationSlotControlLock. Dead lock between > > ReplicationSlotCleanup and InvalidateObsoleteReplicationSlots > > happened? A deadlock requires some form of incorrected lock (or lock like) nesting. Do you have an idea what that could be? > That's possible. Whatever the exact cause of this failure, I think we > can stabilize this test by adding a condition of application_name to > the query. I think the test is telling us that something may be broken. We shouldn't silence that without at least some understanding what it is. It'd be good try to reproduce this locally... - Andres
Commits
-
Revert 019_replslot_limit.pl related debugging aids.
- 49ddd9876362 15.0 landed
- 3f8148c256e0 16.0 landed
-
Don't fail for > 1 walsenders in 019_replslot_limit, add debug messages.
- 91c0570a7911 15.0 landed
-
Add retries for further investigation of 019_replslot_limit.pl failures.
- f28bf667f602 15.0 landed
-
Add further debug info to help debug 019_replslot_limit.pl failures.
- fe0972ee5e6f 15.0 landed
-
Add temporary debug info to help debug 019_replslot_limit.pl failures.
- afdeff10526e 15.0 landed
-
Move replication slot release to before_shmem_exit().
- 2f6501fa3c54 15.0 cited
-
Server-side fix for delayed NOTIFY and SIGTERM processing.
- 2ddb9149d14d 12.0 cited