| From: | Manu <manuelreyesbravo(at)gmail(dot)com> |
|---|---|
| To: | Joao Detomini <joao(dot)detomini(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: doc: Document Linux cgroup memory limits |
| Date: | 2026-10-04 23:42:28 |
| Message-ID: | 179115734820.1481068.16286126838333055817@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-10-05 00:00:00 | Re: Teach pg_upgrade to deal with invalid databases |
| Previous Message | Amit Langote | 2026-10-04 23:37:54 | Re: RI fastpath misses checking EXECUTE on functions |