Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
Subject: Re: debug a lockup
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: 
 <SN7P223MB05809AA60554BD2253269B6DDD62A@SN7P223MB0580.NAMP223.PROD.OUTLOOK.COM>
Date: Tue, 10 Feb 2026 17:12:19 -0700
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A724D8F7-D1F2-401E-8307-618AAF5B2A13@elevated-dev.com>
References: <62854B1F-FE6F-47BD-8B8C-5BEAA33EE3AD@elevated-dev.com>
 <SN7P223MB05809AA60554BD2253269B6DDD62A@SN7P223MB0580.NAMP223.PROD.OUTLOOK.COM>
To: Aislan Luiz Wendling <aislanluiz@hotmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/A724D8F7-D1F2-401E-8307-618AAF5B2A13%40elevated-dev.com>
Precedence: bulk

OK, we figured it out--I think.

pgbench was stuck in restart_syscall(<...resuming interrupted read...

it was set to open 100 connections

there were ~20 pg sessions in idle, and the last one (highest pid) in =
auth

that one was in write to fd 2

So... This is running in kubernetes. I was doing some load testing =
against a storage service (thus 100 connections). PG was launched =
manually in a bash session connected to the pod, in k9s. There were ~20 =
total bash sessions open in k9s across 15 nodes.

Theory: k9s glitched and stopped reading the piped file descriptor, =
buffer filled, and PG blocked on the write. (I have seen prior evidence =
of less-than-perfect handling of output by k9s). Particularly, I had =
logging of connections on, so at auth it would have been writing to =
stderr.

This happened in one of probably over 100 runs of the same test, so not =
readily reproducible and I wanted to autopsy it before killing off the =
hung processes. Unless someone pokes a hole in my theory, at this point =
I think it is neither pgbench nor PG nor Pure/Portworx at fault.

--
Scott Ribe
scott_ribe@elevated-dev.com
https://www.linkedin.com/in/scottribe/