Re: doc: Document Linux cgroup memory limits

From: Joao Detomini <joao(dot)detomini(at)enterprisedb(dot)com>
To: Manu <manuelreyesbravo(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: doc: Document Linux cgroup memory limits
Date: 2026-10-05 00:38:50
Message-ID: CABH8dKxgc=quWPu7JQ2JgHWtwhwM9FftmWUOzr7GsOc3b8akXA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Manu,

Thanks for testing v2 and for the wording. You're right, what goes away
is the automatic restart, not the recovery. v3 attached with your
suggested sentence, slightly reworded to say the server doesn't log the
termination.

Regards,
João Marcelo

Em dom., 4 de out. de 2026 às 20:42, Manu <manuelreyesbravo(at)gmail(dot)com>
escreveu:

> Hi João,
>
> Thanks for v2. It applies to master, the docs build, and the
> hugetlb sentence matches what I see here (systemd 262 mounts cgroup2
> with memory_hugetlb_accounting).
>
> One wording point:
>
> > In that case there is no crash recovery, and the server stops without
> > logging anything.
>
> What goes away is the automatic restart, not the recovery: after a
> SIGKILL of the whole process tree, which is what memory.oom.group
> does, the next start logs "database system was not properly shut
> down; automatic recovery in progress" and replays WAL as usual.
> Perhaps:
>
> In that case the server is not restarted automatically, and nothing
> is logged about the termination.
>
> With that, it looks ready for committer to me.
>
> Regards,
> Manu
>

Attachment Content-Type Size
v3-0001-doc-Document-Linux-cgroup-memory-limits.patch application/octet-stream 4.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2026-10-05 00:46:26 Re: Material node can report incorrect "Maximum Storage" in EXPLAIN
Previous Message Bharath Rupireddy 2026-10-05 00:30:00 Show effective xmin in pg_replication_slots when xmin is not set