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