| 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
| 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() |