From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
---|---|
To: | 'Craig Ringer' <craig(at)2ndquadrant(dot)com>, 'Andres Freund' <andres(at)anarazel(dot)de>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: POC: GUC option for skipping shared buffers in core dumps |
Date: | 2020-02-12 00:55:50 |
Message-ID: | OSAPR01MB5073D59C403946BA3C207A3EFE1B0@OSAPR01MB5073.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Craig Ringer <craig(at)2ndquadrant(dot)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.
From: Andres Freund <andres(at)anarazel(dot)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 start scripts. Or, can they just use pg_ctl's -o to specify new GUC parameters?
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2020-02-12 00:57:05 | Re: Avoiding hash join batch explosions with extreme skew and weird stats |
Previous Message | Jeff Davis | 2020-02-12 00:51:09 | Re: POC: rational number type (fractions) |