Re: POC: GUC option for skipping shared buffers in core dumps - Mailing list pgsql-hackers

From Lepikhov Andrei
Subject Re: POC: GUC option for skipping shared buffers in core dumps
Date
Msg-id 1d51c572-24b6-4061-92b1-417f4b6bb450@app.fastmail.com
Whole thread Raw
In response to RE: POC: GUC option for skipping shared buffers in core dumps  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List pgsql-hackers

On Wed, Feb 12, 2020, at 7:55 AM, tsunakawa.takay@fujitsu.com wrote:
> From: Craig Ringer <craig@2ndquadrant.com>
>> 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...
>
> We have a simple implementation that allows to exclude shared memory.  
> That's been working for years.
>
> [postgresql.conf]
> core_directory = 'location of core dumps'
> core_contents = '{none | minimum | full}'
> # none = doesn't dump core, minimum excludes shared memory, and full dumps all
>
> I can provide it.  But it simply changes the current directory and 
> detaches shared memory when postgres receives signals that dump core.
>
> I made this GUC because Windows also had to be dealt with.

If it's still possible, share your patch here. I don't know what about the core, but during development, especially the
bug-fixingprocess, it is really dull to wait for the core generation process every time, even if you debug a planner
issueand are not interested in shared memory blocks ...
 

-- 
Regards,
Andrei Lepikhov



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add 'worker_type' to pg_stat_subscription
Next
From: Yugo NAGATA
Date:
Subject: Re: Make psql's qeury canceling test simple by using signal() routine of IPC::Run