From: hubert depesz lubaczewski <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
Date: Tue, 4 Jul 2023 15:55:23 +0200
Message-ID: <ZKQky8nApOWI8O/X@depesz.com> (raw)
In-Reply-To: <d25141d4-c390-b74b-53c1-97064d07b7c9@enterprisedb.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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: depesz@depesz.com, tomas.vondra@enterprisedb.com
Subject: Re: Backend handling replication slot stuck using 100% cpu, unkillable
In-Reply-To: <ZKQky8nApOWI8O/X@depesz.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox