Re: BUG #18469: OOM occurs and backend processes are kept in Zombie state.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 2986538596(at)qq(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18469: OOM occurs and backend processes are kept in Zombie state.
Date: 2024-05-16 17:23:37
Message-ID: 2117193.1715880217@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> I was performing a lot of operations on a server deployed with postgresql
> 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, these
> processes were not successfully killed and remained in Zombie state. In the
> meantime, the whole database process seems to be stuck and time out happened
> 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 の May06 10:24 /usr/pgsql/bin/postmaster -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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-05-16 18:45:18 Re: BUG #18468: CREATE TABLE ... LIKE leaves orphaned column reference in extended statistics
Previous Message Tom Lane 2024-05-16 16:58:29 Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption