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

  1. Revert 019_replslot_limit.pl related debugging aids.

  2. Don't fail for > 1 walsenders in 019_replslot_limit, add debug messages.

  3. Add retries for further investigation of 019_replslot_limit.pl failures.

  4. Add further debug info to help debug 019_replslot_limit.pl failures.

  5. Add temporary debug info to help debug 019_replslot_limit.pl failures.

  6. Move replication slot release to before_shmem_exit().

  7. Server-side fix for delayed NOTIFY and SIGTERM processing.