Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id CAOYmi+=Pyf9EuR7dRn46ymV-P9fhUft3qH8mqdS-m9ZksmooEg@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Feb 24, 2025 at 12:30 PM Andres Freund <andres@anarazel.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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Trigger more frequent autovacuums of heavy insert tables
Next
From: Melanie Plageman
Date:
Subject: Re: BitmapHeapScan streaming read user and prelim refactoring