Re: Elusive segfault with 9.3.5 & query cancel

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Elusive segfault with 9.3.5 & query cancel
Date: 2014-12-06 00:01:24
Message-ID: CAM3SWZRqjM5DdODSt5=TiZDAXQwWxXth2AyxF1PUW+4sDkgkog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 5, 2014 at 3:49 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> to enable core dumps on the production replicas because writing out the
> 16GB of shared buffers they had took over 10 minutes in a test.

No one ever thinks it'll happen to them anyway - recommending enabling
core dumps seems like a waste of time, since as Tom mentioned package
managers shouldn't be expected to get on board with that plan. I think
a zero overhead backtrace feature from within a SIGSEGV handler (with
appropriate precautions around corrupt/exhausted call stacks) using
glibc is the right thing here.

Indeed, glibc does have infrastructure that can be used to get a
backtrace [1], which is probably what we'd end up using, but even
POSIX has infrastructure like sigaltstack(). It can be done.

[1] https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-12-06 00:15:08 Re: Elusive segfault with 9.3.5 & query cancel
Previous Message Josh Berkus 2014-12-05 23:49:08 Re: Elusive segfault with 9.3.5 & query cancel