Re: Backend handling replication slot stuck using 100% cpu, unkillable - Mailing list pgsql-bugs

From hubert depesz lubaczewski
Subject Re: Backend handling replication slot stuck using 100% cpu, unkillable
Date
Msg-id ZKQky8nApOWI8O/X@depesz.com
Whole thread Raw
In response to Re: Backend handling replication slot stuck using 100% cpu, unkillable  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-bugs
On Tue, Jul 04, 2023 at 03:04:58PM +0200, Tomas Vondra wrote:
> The backtrace has this:
> and 187650155969544 should be LSN AAAA/B4E37C08, which maps to
> select pg_walfile_name('AAAA/B4E37C08');
>      pg_walfile_name
> --------------------------
>  000000010000AAAA000000B4

We're not that far. Current WAL is 0000000100001D77000000AF

There was command in there, though that referred to wal
0000000100001D6C00000092
I checked pg_waldump of this wal, and found lots of DELETE and NEW_CID
commands on 2 relations: pg_depend and pg_publication_rel

This kinda makes sense given that around that time there was drop of
replication slot, and earlier drop of all tables from it.

Best regards,

depesz




pgsql-bugs by date:

Previous
From: Vamshikrishna T
Date:
Subject: Re: BUG #18009: Postgres Recovery not happening
Next
From: Daniel Gustafsson
Date:
Subject: Re: BUG #17695: Failed Assert in logical replication snapbuild.