Re: Improve OAuth discovery logging

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Improve OAuth discovery logging
Date: 2026-03-04 22:18:16
Message-ID: CAOYmi+=SR_nJJBh7UXZzK8Zbs21L2RUNkW3d9aPRkQOHj1bBPA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[cc'ing Tom for awareness]

On Wed, Mar 4, 2026 at 12:40 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-03-04 22:29:29 Re: Add expressions to pg_restore_extended_stats()
Previous Message Corey Huinker 2026-03-04 22:05:55 Re: Add expressions to pg_restore_extended_stats()