Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)
Date
Msg-id CAB7nPqSkeN-6BJYX-=6JAo4bK_w_+jzZ1p5=T0C-ZRPNnrdbmA@mail.gmail.com
Whole thread Raw
In response to bgw_type (was Re: [HACKERS] Why does logical replication launcher setapplication_name?)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)
Re: bgw_type (was Re: [HACKERS] Why does logical replication launcherset application_name?)
List pgsql-hackers
On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 5/30/17 23:10, Peter Eisentraut wrote:
>> Here is a proposed solution that splits bgw_name into bgw_type and
>> bgw_name_extra.  bgw_type shows up in pg_stat_activity.backend_type.
>> Uses of application_name are removed, because they are no longer
>> necessary to identity the process type.
>
> Updated patch incorporating the feedback.  I have kept bgw_name as it
> was and just added bgw_type completely independently.

-             errmsg("terminating background worker \"%s\" due to
administrator command",
-                    MyBgworkerEntry->bgw_name)));
+             errmsg("terminating %s due to administrator command",
+                    MyBgworkerEntry->bgw_type)));
"terminating background worker %s of type %s due to administrator
command", bgw_name, bgw_type?

> One open question is how to treat a missing (empty) bgw_type.  I
> currently fill in bgw_name as a fallback.  We could also treat it as an
> error or a warning as a transition measure.

Hm. Why not reporting an empty type string as NULL at SQL level and
just let it empty them? I tend to like more interfaces that report
exactly what is exactly registered at memory-level, because that's
easier to explain to users and in the documentation, as well as easier
to interpret and easier for module developers.
-- 
Michael



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Hash Functions
Next
From: Michael Paquier
Date:
Subject: [HACKERS] Upcoming commit fest will begin soon