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: 2026-01-22 02:12:19
Message-ID: 4d496ab8-35e7-4535-8ee1-ed2bb7262172@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 17, 2026, at 7:02 PM, Alvaro Herrera wrote:
>
> I'm not opposed to this idea, but I think it should be implemented not
> by sorting and then moving the first element to the top of the list, but
> instead by modifying the cmp function so that the desired order is
> achieved directly. So the cmp() should return -1 if element a has no
> colon, or 1 if element b has no colon, otherwise return per strcmp.
> That way you can remove the foreach() block above, which is icky.
>

Good idea. The v9 contains this implementation. I also use the StringInfo as
you suggested in the other email. The 0003 removed the wrong B_BACKEND
assignment pointed in a previous email. This new patchset contains some changes
suggested by Japin Li [1] (I didn't change the error message because it adds an
extra message to translate). There was a minor issue with a null-terminated
string that I fixed too.

PS> I didn't change the background worker case that I mentioned in [2].

[1] https://postgr.es/m/MEAPR01MB3031FA1986F3FC91481E28CCB68DA@MEAPR01MB3031.ausprd01.prod.outlook.com
[2] https://postgr.es/m/f20103f2-d960-4206-9969-c4a936524ab1@app.fastmail.com

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

Attachment Content-Type Size
v9-0001-log_min_messages-per-process-type.patch text/x-patch 26.2 KB
v9-0002-sort-log_min_messages-elements-per-process-type.patch text/x-patch 3.4 KB
v9-0003-Assign-backend-type-earlier.patch text/x-patch 8.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2026-01-22 02:24:56 Re: LLVM 22
Previous Message Andres Freund 2026-01-22 01:59:45 Re: Having problems generating a code coverage report