Re: [PoC] Federated Authn/z with OAUTHBEARER

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: 2025-02-24 22:02:04
Message-ID: CAOYmi+=Pyf9EuR7dRn46ymV-P9fhUft3qH8mqdS-m9ZksmooEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 24, 2025 at 12:30 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> If you need to handle the race it you need to combine it with something
> additional, e.g. the so called "self pipe trick". Which e.g. the latch / wait
> event set code does.

Right; I'm just used to that trick being deployed in massively
parallel async event engines rather than linear synchronous code
waiting on a single descriptor. I'm still a bit in disbelief, to be
honest. I'll get over it. Thank you for the note!

> > A bit. The same for Kerberos, IIRC. Is the current configure warning
> > not strong enough to imply that the packager is on shaky ground?
>
> I don't think it's strong enough.
>
> > (I patterned that off of the LDAP crash warning, which seemed much worse to
> > me. :D)
>
> I don't think that's a comparable case, because there were in-production uses
> of PG+ldap that (kind of) worked. Whereas we start on a green field here.

Fair enough. I'll work on a patch to disallow it; best case, no one
ever complains, and we've pruned an entire configuration from the list
of things to worry about.

Thanks!
--Jacob

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-02-24 22:07:31 Re: BitmapHeapScan streaming read user and prelim refactoring
Previous Message Nathan Bossart 2025-02-24 21:53:48 Re: Trigger more frequent autovacuums of heavy insert tables