Re: log_min_messages per backend type

From: "Euler Taveira" <euler(at)eulerto(dot)com>
To: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: japin <japinli(at)hotmail(dot)com>, "Andres Freund" <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, "Chao Li" <li(dot)evan(dot)chao(at)gmail(dot)com>
Subject: Re: log_min_messages per backend type
Date: 2025-11-26 02:11:46
Message-ID: 144f0f96-c6d3-4ad6-a236-00200513e2e0@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 21, 2025, at 11:13 AM, Euler Taveira wrote:
> 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).
>

After digesting it for a couple of days, I decided to adopt the terminology in
commit dbf8cfb4f02e (process type) just for this patch. This discussion about
changing "backend type" terminology in other parts belongs to another patch.

>>> 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.
>

After reflection, add B_POSTMASTER into BackendType / proctypelist.h is not a
good idea. These data structures were designed to represent postmaster
children. The child_process_kinds array (launch_backend.c) is assembled with
proctypelist.h which means a function like postmaster_child_launch() could use
one of its elements (e.g. B_POSTMASTER) to start a new child; that's awkward. Do
you envision any issues to use B_INVALID for postmaster? (I wrote 0002 to
minimize the windows that each child process has B_INVALID.)

This new version contains the following changes:

- fix variable assignment (Chao Li)
- fix memory release order (Chao Li)
- change category for B_INVALID (backend -> postmaster) (Alvaro)
- rewrite documentation (Chao Li, Alvaro)
- rename backend type to process type (Alvaro)
- new patch (0002) that assigns MyBackendType as earlier as possible

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

Attachment Content-Type Size
v6-0001-log_min_messages-per-process-type.patch text/x-patch 26.3 KB
v6-0002-Assign-backend-type-earlier.patch text/x-patch 7.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2025-11-26 02:15:21 Re: log_min_messages per backend type
Previous Message Michael Paquier 2025-11-26 02:06:10 Re: Extended Statistics set/restore/clear functions.