Re: Improve OAuth discovery logging - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Improve OAuth discovery logging
Date
Msg-id 1B58D836-6B8F-4B9A-9B84-08965E5AA06B@yandex-team.ru
Whole thread
In response to Re: Improve OAuth discovery logging  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: Improve OAuth discovery logging
List pgsql-hackers

> On 16 Mar 2026, at 12:32, Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> Thanks for the quick review!
>
>> pg_stat_database.sessions_fatal seems to be still incremented, but, probably,
>> we can live with it. But also we can fix it.
>
> We are still doing a fatal disconnect, so it seems appropriate to me?

Makes sense. We must see this activity somewhere. Even establishing connection is
a big deal, let alone TLS handshake.

>
>> Changes to send_message_to_server_log()
>> ...
>> FATAL_CLIENT_ONLY = 23 sits between FATAL (22) and PANIC (24).
>
> I handled these the same way as the existing WARNING_CLIENT_ONLY. We
> can change it, but then we probably should also update the warning
> case.

Ahh, OK.

>
>> Does this assignment have an effect?
>
> No, but that's also true for the other already existing assignment in
> this branch, I think these are mostly there for internal
> bookkeeping/consistency?

OK.

One more nit: errdetail("Empty request, discovery requested?").
Question marks are uncommon in errdetail and errmsg.

I have no more comments about the patch, feel free to flip it to RfC.


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Add missing stats_reset column to pg_statio_all_sequences view
Next
From: Xuneng Zhou
Date:
Subject: Re: Odd code around ginScanToDelete