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 13:53:43 +0200
Message-ID: <ZKQIR0DpwoFut57r@depesz.com> (raw)
In-Reply-To: <b30f3919-6181-cbf9-4011-e6fb374dba91@enterprisedb.com>
References: <ZKKywNsS9tR/3R80@depesz.com>
<ZKLF3zT4kV+VUGjJ@depesz.com>
<b30f3919-6181-cbf9-4011-e6fb374dba91@enterprisedb.com>
On Tue, Jul 04, 2023 at 01:30:21PM +0200, Tomas Vondra wrote:
> On 7/3/23 14:58, hubert depesz lubaczewski wrote:
> So is it an infinite loop in ReorderBufferExecuteInvalidations, or is it
> just the case that there are many invalidations? I can't really deduce
> that from the backtraces.
>
> How many invalidations does the transaction have? Should be enough to
>
> print txn->ninvalidations
>
> Also, is there anything interesting about the transaction? You know the
> XID (2741814901) so maybe use pg_waldump to see what it did.
I don't have the process anymore. Pg was restarted, and the app was
forced to not take data from this place.
I can run pg_waldump, no problem, but I'm not an expert on this. Which
wal file(s) should I try to dump? and what to look for (or should I just
provide full output of dump?
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: <ZKQIR0DpwoFut57r@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