Thread

Re: log_min_messages per backend type

Alvaro Herrera <alvherre@alvh.no-ip.org> — 2025-11-19T10:44:17Z

On 2025-Nov-18, Euler Taveira wrote:

> On Thu, Nov 6, 2025, at 1:01 PM, Alvaro Herrera wrote:

> See miscadmin.h.
> 
> /*
>  * MyBackendType indicates what kind of a backend this is.
>  *
>  * If you add entries, please also update the child_process_kinds array in
>  * launch_backend.c.
>  */
> typedef enum BackendType
> 
> 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.

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

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

> You said table but it is a multi-column list; it doesn't contain a
> header or borders.

Right.  You don't need a full-blown table here: this simple list is
perfectly adequate.

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

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/