Re: Why does logical replication launcher set application_name?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why does logical replication launcher set application_name?
Date: 2017-06-07 12:29:41
Message-ID: CABUevEwdmPgyh41hP0G3OLjCPZHsyfV95Nuwrq8v6dd_NGjUkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 7, 2017 at 4:58 AM, Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 6/6/17 15:58, Robert Haas wrote:
> > The problem with the status quo (after Peter's commit) is that there's
> > now nothing at all to identify the logical replication launcher, apart
> > from the wait_event field, which is likely to be LogicalLauncherMain
> > fairly often if you've got the launcher. I don't personally see why
> > we can't simply adopt Tom's original proposal of setting the query
> > string to something like "<logical replication launcher>" which, while
> > maybe not as elegant as providing some way to override the
> > backend_type field, would be almost no work and substantially better
> > for v10 than what we've got now.
>
> The decision was made to add background workers to pg_stat_activity, but
> no facility was provided to tell the background workers apart. Is it
> now the job of every background worker to invent a hack to populate some
> other pg_stat_activity field with some ad hoc information? What about
> other logical replication worker types, parallel workers, external
> background workers, auto-prewarm?
>
> I think the bgw_type addition that I proposed nearby would solve this
> quite well, but it needs a bit of work. And arguably, it's too late for
> PG10, but one could also argue that this is a design fault in the
> pg_stat_activity extension that is valid to fix in PG10.
>

+1. I definitely think it would be a bad idea to put in what basically
looks like a workaround into 10, since the new feature was added there. I'd
rather have the fix for pg_stat_activity.

We used to keep our query state as a text field and that was a bad idea for
many reasons. So we moved it to a separate field. Let's not repeat that
mistake here.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-06-07 12:34:06 Re: HACKERS[PROPOSAL] split ProcArrayLock into multiple parts
Previous Message Robert Haas 2017-06-07 12:27:05 Re: Proposal : For Auto-Prewarm.