On Tue, 11 Feb 2020 at 03:07, Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
>
> Hi!
>
> In Postgres Pro we have complaints about too large core dumps. The
> possible way to reduce code dump size is to skip some information.
> Frequently shared buffers is most long memory segment in core dump.
> For sure, contents of shared buffers is required for discovering many
> of bugs. But short core dump without shared buffers might be still
> useful. If system appears to be not capable to capture full core
> dump, short core dump appears to be valuable option.
>
> Attached POC patch implements core_dump_no_shared_buffers GUC, which
> does madvise(MADV_DONTDUMP) for shared buffers. Any thoughts?
I'd like this a lot. In fact I'd like it so much I kinda hope it'd be
considered backpatchable because coredump_filter is much too crude and
coarse grained.
Now that Pg has parallel query we all rely on shm_mq, DSM/DSA, etc.
It's increasingly problematic to have these areas left out of core
dumps in order to avoid bloating them with shared_buffers contents.
Doubly so if, like me, you work with extensions that make very heavy
use of shared memory areas for their own IPC.
Currently my options are "dump all shmem including shared_buffers" or
"dump no shmem". But I usually want "dump all shmem except
shared_buffers". It's tolerable to just dump s_b on a test system with
a small s_b, but if enabling coredumps to track down some
hard-to-repro crash on a production system I really don't want 20GB
coredumps...
Please, please apply.
Please backpatch, if you can possibly stand to do so.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
