Re: shared-memory based stats collector

Hi,

On 2020-03-10 19:52:22 +0100, Julien Rouhaud wrote:
> On Tue, Mar 10, 2020 at 1:48 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> >
> > On 2020-Mar-10, Kyotaro Horiguchi wrote:
> >
> > > At Mon, 9 Mar 2020 20:34:20 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> > > > On 2020-03-10 12:27:25 +0900, Kyotaro Horiguchi wrote:
> > > > > That's true, but I have the same concern with Tom. The archive bacame
> > > > > too-tightly linked with other processes than actual relation.
> > > >
> > > > What's the problem here? We have a number of helper processes
> > > > (checkpointer, bgwriter) that are attached to shared memory, and it's
> > > > not a problem.
> > >
> > > That theoretically raises the chance of server-crash by a small amount
> > > of probability. But, yes, it's absurd to prmise that archiver process
> > > crashes.
> >
> > The case I'm worried about is a misconfigured archive_command that
> > causes the archiver to misbehave (exit with a code other than 0); if
> > that already doesn't happen, or we can make it not happen, then I'm okay
> > with the changes to archiver.
>
> Any script that gets killed, or that exit with a return code > 127
> would do that.

But just with a FATAL, not with something worse. And the default
handling for aux backends accepts exit code 1 (which elog uses for
FATAL) as a normal shutdown. Am I missing something here?

Greetings,

Andres Freund