Feedback-ID: i0c21471d:Fastmail
MIME-Version: 1.0
Date: Fri, 21 Nov 2025 11:13:01 -0300
From: "Euler Taveira" <euler@eulerto.com>
To: "Alvaro Herrera" <alvherre@alvh.no-ip.org>
Cc: japin <japinli@hotmail.com>, "Andres Freund" <andres@anarazel.de>,
 pgsql-hackers@lists.postgresql.org
Message-Id: <6594c13d-6582-46f3-93fd-86e69275262d@app.fastmail.com>
In-Reply-To: <202511191005.57xh2abe6zrx@alvherre.pgsql>
References: <202511191005.57xh2abe6zrx@alvherre.pgsql>
Subject: Re: log_min_messages per backend type
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/6594c13d-6582-46f3-93fd-86e69275262d%40app.fastmail.com>
Precedence: bulk

On Wed, Nov 19, 2025, at 7:44 AM, Alvaro Herrera wrote:
> On 2025-Nov-18, Euler Taveira wrote:
>> The "backend type" terminology is exposed.
>
> Something appearing in the source code does not equate it being exposed
> to end users.  Things are exposed when they are in the documentation, or
> when the SQL interface requires you to use the term.  So I don't think
> the fact that BackendType appears in the code forces us to use that name
> in the user-visible interface now.
>

It is *already* exposed.

$ grep -B 3 -A 3 'backend type' doc/src/sgml/config.sgml 
         </informaltable>

         <para>
          The backend type corresponds to the column
          <structfield>backend_type</structfield> in the view
          <link linkend="monitoring-pg-stat-activity-view">
          <structname>pg_stat_activity</structname></link>,
--
        character count of the error position therein,
        location of the error in the PostgreSQL source code
        (if <varname>log_error_verbosity</varname> is set to <literal>verbose</literal>),
        application name, backend type, process ID of parallel group leader,
        and query id.
        Here is a sample table definition for storing CSV-format log output:

$ grep -B 3 -A 3 'backend_type' doc/src/sgml/config.sgml 

         <para>
          The backend type corresponds to the column
          <structfield>backend_type</structfield> in the view
          <link linkend="monitoring-pg-stat-activity-view">
          <structname>pg_stat_activity</structname></link>,
          but additional types can appear
--
  query_pos integer,
  location text,
  application_name text,
  backend_type text,
  leader_pid integer,
  query_id bigint,
  PRIMARY KEY (session_id, session_line_num)
--
         <entry>Client application name</entry>
        </row>
        <row>
         <entry><literal>backend_type</literal></entry>
         <entry>string</entry>
         <entry>Type of backend</entry>
        </row>

$ psql -c "SELECT backend_type FROM pg_stat_activity" -d postgres
         backend_type         
------------------------------
 client backend
 autovacuum launcher
 logical replication launcher
 io worker
 io worker
 io worker
 checkpointer
 background writer
 walwriter
(9 rows)

> In the glossary, we talk about "processes"; in the definitions there,
> "backend" is one type of process.  So in this list of "backend types"
> that you want to introduce, what you really should be talking about is
> "process types", where "backend" is one of the options.
>
>> It is even available in the
>> pg_stat_activity view. I agree that "backend" is not a good name to define a
>> Postgres process. I don't think we should be inconsistent only in this patch.
>> Even if the proposal is to rename enum BackendType (I won't propose it as part
>> of this patch), it would make some extension authors unhappy according to
>> codesearch.debian.net.
>
> I don't think we should rename the BackendType enum.  That's in the
> source code, not in the documentation or the SQL interface, so we don't
> need to care.
>

I think you missed my point here. As I said if your proposal will let us with 2
terminologies (backend type and process type) as shown above.  We can debate if
we (1) keep the current terminology (backend type), (2) use the proposed one
(process type) or (3) use a mixed variation (keep the SQL interface --
backend_type column but change the description to "process type"). I wouldn't
like to break compatibility (pg_stat_activity changes tend to break a lot of
stuff) so I'm fine with (1) and (3).

>> > I think the list of backend types is pretty hard to read.  What do you
>> > think about using 
>> > <simplelist type="vert" columns="4">
>> > to create a friendlier representation?  
>> 
>> I tried but didn't like the result. See the attached image.
>
> Well, I like it very much.  The original is a solid wall of text, very
> hard to read, where you have to squint hunting commas in order to
> distinguish one item from the next.  (Maybe you are young and have good
> eyesight, but you won't be young forever.)  In the screenshot you show,
> the list of possible process types to use is nicely separated, which
> makes it very easy to catch at a glance.  Maybe remove "the table",
> which is obviously inappropriate, and just say "Valid process types are
> listed below, each corresponding to either postmaster, an auxiliary
> process type or a backend".
>

I don't have a strong preference. One advantage of this suggestion is that it 
is visually easier to identify the types.

> (Note your original wording says "a backend type, corresponding to [blah
> blah] or a backend" which makes no sense -- how is a backend a type of
> backend?  It isn't.  It's a type of process.)
>

I'm rewriting that paragraph.

>> Good question. The current patch uses "backend" to B_INVALID (that's exactly the
>> MyBackendType for postmaster -- see below). I think it is reasonable to create a
>> new category "postmaster" and assign it to B_INVALID.
>
> I guess that would work, but I think it's inadequate.  Maybe we could
> add a new value B_POSTMASTER and have postmaster switch to that as early
> as possible.  Then anything that still has B_INVALID must necessarily be
> an improperly identified process.  Users wouldn't assign a value to that
> one (the GUC wouldn't let you); instead those would always use the
> default value.  Hopefully nobody would see that very often, or at all.
>

I will create a separate patch for this suggestion.


-- 
Euler Taveira
EDB   https://www.enterprisedb.com/