| 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 |
| 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 |