From: Tom Lane <tgl@sss.pgh.pa.us>
To: 2986538596@qq.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18469: OOM occurs and backend processes are kept in Zombie
 state.
In-reply-to: <18469-d89fa2c627b01893@postgresql.org>
References: <18469-d89fa2c627b01893@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 16 May 2024 10:55:03 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2117192.1715880217.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 May 2024 13:23:37 -0400
Message-ID: <2117193.1715880217@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2117193.1715880217%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> I was performing a lot of operations on a server deployed with postgresq=
l
> 12.16. As heavy operations  performed continuously.  memory consumption =
has
> been increased, the OS eventually got OOM and some background connection
> processes that were taking up too much memory were killed. However, thes=
e
> processes were not successfully killed and remained in Zombie state. In =
the
> meantime, the whole database process seems to be stuck and time out happ=
ened
> while connect via psql.

It sounds to me like the OOM killer decided to kill the postmaster
process, rather than the child process(es) that were actually eating
memory.  That's *extremely* unhelpful behavior.  There is some advice
in our manual about configuring your system to not do that.

> Below is the status  after OOM happened:
> Ruby	7822	0.0	0.6 4485088 110940	=E3=81=AE	May06	10:24 /usr/pgsql/bin/po=
stmaster -D /var/lib/pgsql/data

It's not clear to me where this postmaster process came from,
but it appears to be younger than the other postgres-related
processes you're showing, so they are not its children.

I'd manually nuke all of these processes and start fresh.

			regards, tom lane