Re: shared-memory based stats collector

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: andres(at)anarazel(dot)de, tgl(at)sss(dot)pgh(dot)pa(dot)us, michael(at)paquier(dot)xyz, thomas(dot)munro(at)gmail(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, a(dot)zakirov(at)postgrespro(dot)ru, ah(at)cybertec(dot)at, magnus(at)hagander(dot)net, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared-memory based stats collector
Date: 2020-03-10 12:48:07
Message-ID: 20200310124807.GA29194@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2020-03-10 12:58:41 Re: WIP: System Versioned Temporal Table
Previous Message Filip Janus 2020-03-10 12:47:14 Ecpg dependency