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

From tsunakawa.takay@fujitsu.com
Subject RE: POC: GUC option for skipping shared buffers in core dumps
Date
Msg-id OSAPR01MB5073D59C403946BA3C207A3EFE1B0@OSAPR01MB5073.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: POC: GUC option for skipping shared buffers in core dumps  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: POC: GUC option for skipping shared buffers in core dumps
List pgsql-hackers
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
signalsthat dump core.
 

I made this GUC because Windows also had to be dealt with.


From: Andres Freund <andres@anarazel.de>
> > Hah.  This argument boils down to saying our packagers suck :-)
> 
> Hm? I'd say it's a sign of respect to not have each of them do the same
> work. Especially when they can't address it to the same degree core PG
> can. So maybe I'm saying we shouldn't be lazy ;)

Maybe we should add options to pg_ctl just like -c which is available now, so that OS packagers can easily use in their
startscripts.  Or, can they just use pg_ctl's -o to specify new GUC parameters?
 


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: POC: rational number type (fractions)
Next
From: Melanie Plageman
Date:
Subject: Re: Avoiding hash join batch explosions with extreme skew and weird stats