Message-ID: <b30f3919-6181-cbf9-4011-e6fb374dba91@enterprisedb.com>
Date: Tue, 4 Jul 2023 13:30:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: Backend handling replication slot stuck using 100% cpu,
 unkillable
Content-Language: en-US
To: depesz@depesz.com, pgsql-bugs mailing list <pgsql-bugs@postgresql.org>
References: <ZKKywNsS9tR/3R80@depesz.com> <ZKLF3zT4kV+VUGjJ@depesz.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <ZKLF3zT4kV+VUGjJ@depesz.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b30f3919-6181-cbf9-4011-e6fb374dba91%40enterprisedb.com>
Precedence: bulk

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