Hi,
On 2020-02-10 18:21:30 -0300, Alvaro Herrera wrote:
> On 2020-Feb-10, Andres Freund wrote:
>
> > Hi,
> >
> > On 2020-02-10 17:31:47 -0300, Alvaro Herrera wrote:
> > > Yeah. Maybe we should file bug reports against downstream packages to
> > > include a corefilter tweak.
> >
> > Hm, I'm not sure that's a reasonable way to scale things. Nor am I
> > really sure that's the right granularity.
>
> 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 ;)
> > > I don't know how easy is it to teach systemd to do this on its service
> > > files.
> >
> > Well, you could just make it part of the command that starts the
> > server. Not aware of anything else.
>
> I tried to do that, but couldn't figure out a clean way, because you
> have to do it after the fact (not in the process itself). Maybe it's
> possible to have pg_ctl do it once postmaster is running.
Shouldn't it be sufficient to just do it to /proc/self/coredump_filter?
It's inherited IIUC?
Yep:
A child process created via fork(2) inherits its parent's coredump_filter value; the coredump_filter value is
preservedacross an execve(2).
> > > But maybe we should have a way to disable the corefiltering.
> >
> > There should, imo. That's why I was wondering about making this a GUC
> > (presumably suset).
>
> Not really sure about suset ... AFAIR that means superuser can SET it;
> but what you really care about is more like ALTER SYSTEM, which is
> SIGHUP unless I misremember.
I really want both. Sometimes it's annoying to get followup coredumps by
other processes, even if I just want to get a corefile from one process
doing something more specific. It seems nice to alter that session /
user to have large coredumps, but not the rest?
Greetings,
Andres Freund