Re: shared-memory based stats collector - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: shared-memory based stats collector
Date
Msg-id CAOBaU_Y5jq43kjkkEx1ybzxo2c7rQfDTmwzwVw0UkqN-JUO4hA@mail.gmail.com
Whole thread Raw
In response to Re: shared-memory based stats collector  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: shared-memory based stats collector  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Mar 10, 2020 at 1:48 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2020-Mar-10, Kyotaro Horiguchi wrote:
>
> > At Mon, 9 Mar 2020 20:34:20 -0700, Andres Freund <andres@anarazel.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.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: BEFORE ROW triggers for partitioned tables
Next
From: Tom Lane
Date:
Subject: Re: Constraint's NO INHERIT option is ignored in CREATE TABLE LIKE statement