On 8/30/21 3:34 PM, Justin Pryzby wrote:
On Mon, Aug 30, 2021 at 09:09:20PM +0200, Laurenz Albe wrote:
On Mon, 2021-08-30 at 17:18 +0200, hubert depesz lubaczewski wrote:
> The thing is - I can't close it with pg_terminate_backend(), and I'd
> rather not kill -9, as it will, I think, close all other connections,
> and this is prod server.
Of course the cause should be fixed, but to serve your immediate need:
You might save a coredump of the process using gdb gcore before killing it, in
case someone thinks how to debug it next month.
Depending on your OS, you might have to do something special to get shared
buffers included in the dump (or excluded, if that's what's desirable).
I wonder how far up the stacktrace it's stuck ?
You could set a breakpoint on LogicalDecodingProcessRecord and then "c"ontinue,
and see if it hits the breakpoint in a few seconds. If not, try the next
frame until you know which one is being called repeatedly.
Maybe CheckForInterrupts should be added somewhere...
The spot in the backtrace...
#0 hash_seq_search (status=status@entry=0xffffdd90f380) at
./build/../src/backend/utils/hash/dynahash.c:1448
...is in the middle of this while loop:
8<-----------------------------------------
while ((curElem = segp[segment_ndx]) == NULL)
{
/* empty bucket, advance to next */
if (++curBucket > max_bucket)
{
status->curBucket = curBucket;
hash_seq_term(status);
return NULL; /* search is done */
}
if (++segment_ndx >= ssize)
{
segment_num++;
segment_ndx = 0;
segp = hashp->dir[segment_num];
}
}
8<-----------------------------------------
It would be interesting to step through a few times to see if it is
really stuck in that loop. That would be consistent with 100% CPU and
not checking for interrupts I think.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
