MIME-Version: 1.0
References: 
 <CAN4CZFPim7hUiyb7daNKQPSZ8CvQRBGkVhbvED7yZi8VktSn4Q@mail.gmail.com>
 <7DB528BA-C7A0-4B23-890C-5332FB35A16E@yesql.se>
 <CAN4CZFNNfhFCQdFWui5HWbQR60eM-cyndZ7YgSv7b5SKxB9C2A@mail.gmail.com>
 <CAOYmi+mDSmh6RNizHRmMAwg4ZP2W=uai3Fr3-wm186NMypf_Pg@mail.gmail.com>
 <CAN4CZFNJftK8NaREYaLi-wqpEz3=crQ=1+3f_XUVji=aOrDSWA@mail.gmail.com>
 <7094F798-8DD1-4974-9A04-10E147B29581@gmail.com>
 <CAOYmi+kjtmRMBdBU3_bGKGDoRSK2AErXbGtHkAjFRapcQNmjhA@mail.gmail.com>
 <CAN4CZFNWBXtF-ML3yzdOvX3QEuUwVo5VrBzyWU3O=y-7SeDstA@mail.gmail.com>
 <15434512-B3FB-4AB3-B6B3-5D85ED0B4BBE@yandex-team.ru>
 <CAN4CZFNscs=hiOkRJYF39r7AD7ef9+MR+O2BQdEtE_2Ajdo5qw@mail.gmail.com>
 <CAOYmi+nVzkoLjzNk_58e0NnUPi9uVXwmurK2QP6CzC2WOpqwbg@mail.gmail.com>
 <CAN4CZFPjiUQbKo2q+ovs--AHkjvaE8OJyncB9xu5b+1gp=HHPQ@mail.gmail.com>
 <CAOYmi+=SR_nJJBh7UXZzK8Zbs21L2RUNkW3d9aPRkQOHj1bBPA@mail.gmail.com>
 <CAN4CZFO7ju7fjjv+qwObP8_V-Tdx463zV8F7u_s6wtg9ANVWVg@mail.gmail.com>
 <CAOYmi+kEYA0Tp2son-+Ti1wvSAPov87AVFf4qXATTOHRX1F2gg@mail.gmail.com>
 <CAN4CZFOmym1BaV_U2V56aOyRp2JMrw5nfn6kwcAEcu_RWK-F3Q@mail.gmail.com>
 <99C6E80B-8770-41C2-8084-BF3C7F389FFF@yandex-team.ru>
 <CAN4CZFN7u1kX3_0cfyVvtfiWpORxnvZo=xCr9Ag-F5Onp-hpbA@mail.gmail.com>
 <1B58D836-6B8F-4B9A-9B84-08965E5AA06B@yandex-team.ru>
 <CAOYmi+kxfGEKw7frQPxWYEA6Qe4BLc683UCNPTYCLdCCV0b4Jw@mail.gmail.com>
 <CAN4CZFP--Ec8hMgpu7JojgK9qS08bNnev0c6goA++T4Ozy8bOQ@mail.gmail.com>
 <CAOYmi+nsK1dSXaB+oicoyA6kM9ymygCLhSiKtkg1ph_P1uhYOQ@mail.gmail.com>
 <1AB529D5-6F5D-426D-AB99-12BB7DD394D3@gmail.com>
In-Reply-To: <1AB529D5-6F5D-426D-AB99-12BB7DD394D3@gmail.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Tue, 17 Mar 2026 05:29:04 +0000
Message-ID: 
 <CAN4CZFOwmgyv1002=EZTSM__97gX-1fG0Q3Q4Zy=XviVtZPRxg@mail.gmail.com>
Subject: Re: Improve OAuth discovery logging
To: Chao Li <li.evan.chao@gmail.com>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>,
 Andrey Borodin <x4mmm@yandex-team.ru>,
	Daniel Gustafsson <daniel@yesql.se>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFOwmgyv1002%3DEZTSM__97gX-1fG0Q3Q4Zy%3DXviVtZPRxg%40mail.gmail.com>
Precedence: bulk

> As is_log_level_output() returns false against FATAL_CLIENT_ONLY, so that FATAL_CLIENT_ONLY should not reach send_message_to_server_log(). Should we assert edata->elevel != FATAL_CLIENT_ONLY?

Andrey asked the same question upthread, this mirrors how
WARNING_CLIENT_ONLY is implemented.

> As far as I understand, for a programmer error, Assert should be used. Why do we use elog(ERROR) here?

+1, I would also say that for CheckSASLAuth, specifying abandoned is
always required, since the caller can't know when it will result in an
error. So the assert/if should be at the beginning of the function,
not in the error path.

Or instead:

+ /*
+ * "Abandoned" is a SASL-specific state similar to STATUS_EOF, in that we
+ * don't want to generate any server logs. But it's caused by an in-band
+ * client action that requires a server response, not an out-of-band
+ * connection closure, so we can't just proc_exit() like we do with
+ * STATUS_EOF.
+ */
+ bool abandoned = false;
+

Have you considered adding the error level here instead, the same way
as in auth_failed, explicitly defaulted to normal fatal by the caller,
so existing code don't have to change it? That wouldn't need an
SASL-specific explanation or flag in the generic code.