Re: Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().
Date: 2016-08-22 20:41:05
Message-ID: CA+TgmoYw296PTpQ+iFqcqWECR5x9QW-TE+Rd5Lv9=p0XCxZvOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 16, 2016 at 7:41 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> I still think it's worth thinking about something along these lines on
> Linux only, where holey Swiss tmpfs files can bite you. Otherwise
> disabling overcommit on your OS isn't enough to prevent something
> which is really a kind of deferred overcommit with a surprising
> failure mode (SIGBUS rather than OOM SIGKILL).

Yeah, I am inclined to agree. I mean, creating a DSM is fairly
heavyweight already, so one extra system call isn't (I hope) a crazy
overhead. We could test to see how much it slows things down. But it
may be worth paying the cost even if it ends up being kinda expensive.
We don't really have any way of knowing whether the caller's request
is reasonable relative to the amount of virtual memory available, and
converting a possible SIGBUS into an ereport(ERROR, ...) is a big win.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-08-22 20:50:11 Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)
Previous Message Robert Haas 2016-08-22 20:32:46 Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)