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>
In-Reply-To: 
 <CAN4CZFPjiUQbKo2q+ovs--AHkjvaE8OJyncB9xu5b+1gp=HHPQ@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Wed, 4 Mar 2026 14:18:16 -0800
Message-ID: 
 <CAOYmi+=SR_nJJBh7UXZzK8Zbs21L2RUNkW3d9aPRkQOHj1bBPA@mail.gmail.com>
Subject: Re: Improve OAuth discovery logging
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Chao Li <li.evan.chao@gmail.com>,
	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"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2B%3DSR_nJJBh7UXZzK8Zbs21L2RUNkW3d9aPRkQOHj1bBPA%40mail.gmail.com>
Precedence: bulk

[cc'ing Tom for awareness]

On Wed, Mar 4, 2026 at 12:40=E2=80=AFPM Zsolt Parragi <zsolt.parragi@percon=
a.com> wrote:
> Looks like we have some out of order logging, because of the multiple
> backends involved.

Ugh. In retrospect, then, my commit ab8af1db4 was probably useless. It
doesn't improve any existing usage and it can't help future usage.

> I'm not sure which solution is better for this: removing the check for
> this message from the test

The log_unlike() part is the important bit, so that would be my
preference. Unfortunately that means the intermittent false failure
becomes an intermittent false success, but unless I'm missing
something, we might not be able to do better with the current tools.

> or modifying connect_ok

Well, connect_fails() would seem to suffer the same problem, right?
Tom's solution in e0f373ee4 was never meant to handle concurrent
backends.

I hadn't really considered that all "normal" OAuth connections can
have two concurrent backends in practice. (I think of them as serial,
but they're not.) We're just getting lucky that we haven't made use of
log_[un]like in many problematic cases yet.

> to wait for all
> backends that started since the connection attempt to finish?

Easier said than done, I think. I've wanted to teach the server how to
bracket logs of interest for testing purposes for a while now; I don't
mind using this as a catalyst. But I don't think it should be done as
part of this thread.

Thanks,
--Jacob