Date: Tue, 4 Jul 2023 15:55:23 +0200
From: hubert depesz lubaczewski <depesz@depesz.com>
Sender: depesz@depesz.com
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: pgsql-bugs mailing list <pgsql-bugs@postgresql.org>
Subject: Re: Backend handling replication slot stuck using 100% cpu,
 unkillable
Message-ID: <ZKQky8nApOWI8O/X@depesz.com>
Reply-To: depesz@depesz.com
References: <ZKKywNsS9tR/3R80@depesz.com>
 <ZKLF3zT4kV+VUGjJ@depesz.com>
 <b30f3919-6181-cbf9-4011-e6fb374dba91@enterprisedb.com>
 <ZKQIR0DpwoFut57r@depesz.com>
 <d25141d4-c390-b74b-53c1-97064d07b7c9@enterprisedb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <d25141d4-c390-b74b-53c1-97064d07b7c9@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZKQky8nApOWI8O/X%40depesz.com>
Precedence: bulk

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