Re: Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, amul sul <sul_amul@yahoo.co.in>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-08-16T23:39:14Z
Lists: pgsql-hackers
On Thu, Jun 29, 2017 at 12:24 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > fallocate-v5.patch Added to commitfest so we don't lose track of this. I'm mainly concerned about the fact that we have a way for PostgreSQL to die that looks exactly like a bug, when really it's masking an out-of-memory condition that a DBA or sysadmin would normally be able to diagnose by the appearance of the OOM reaper at the window holding a scythe. I suppose the SIGBUS case is much more likely to happen when we start actively using large amounts of dynamic shared memory (parallel hash), but I suppose it could happen now if your system is already overcommitted and a small DSM segment happens to push you over the edge. -- Thomas Munro http://www.enterprisedb.com
Commits
-
Fix failure-to-read-man-page in commit 899bd785c.
- e5c058e2eed8 9.4.15 landed
- 06852f21544c 9.5.10 landed
- 12ac252f9014 9.6.6 landed
- d29f30d8c3b2 10.0 landed
- 5ea96efaa010 11.0 landed
-
Avoid SIGBUS on Linux when a DSM memory request overruns tmpfs.
- 3a07a6f3e8d2 9.4.15 landed
- 175061222470 9.6.6 landed
- 05297416f362 9.5.10 landed
- 899bd785c0ed 11.0 landed
- 4621c7f7a432 10.0 landed