Re: Backend handling replication slot stuck using 100% cpu, unkillable

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: depesz(at)depesz(dot)com, pgsql-bugs mailing list <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Backend handling replication slot stuck using 100% cpu, unkillable
Date: 2023-07-04 11:30:21
Message-ID: b30f3919-6181-cbf9-4011-e6fb374dba91@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 7/3/23 14:58, hubert depesz lubaczewski wrote:
> ...
>
> and then it went back to hash_seq_search :(
>

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.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message hubert depesz lubaczewski 2023-07-04 11:52:31 Re: Backend handling replication slot stuck using 100% cpu, unkillable
Previous Message PG Bug reporting form 2023-07-04 11:00:01 BUG #18014: Releasing catcache entries makes schema_to_xmlschema() fail when parallel workers are used