Horton

Re: log_min_messages per backend type

Euler Taveira <euler@eulerto.com>

View thread
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, "Chao Li" <li.evan.chao@gmail.com>
Date: 2025-11-26T02:11:46Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow log_min_messages to be set per process type

  2. Assign "backend" type earlier during process start-up

  3. Use integer backend type when exec'ing a postmaster child

  4. Sort guc_parameters.dat alphabetically by name

  5. Create a separate file listing backend types

Attachments

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/