public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: Christoph Berg <[email protected]>
To: Jacob Champion <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
To: Peter Eisentraut <[email protected]>
To: Andres Freund <[email protected]>
To: Tom Lane <[email protected]>
To: Bruce Momjian <[email protected]>
To: PostgreSQL Hackers <[email protected]>
To: Daniel Gustafsson <[email protected]>
To: Thomas Munro <[email protected]>
To: Nazir Bilal Yavuz <[email protected]>
To: Antonin Houska <[email protected]>
To: Wolfgang Walther <[email protected]>
To: Devrim Gündüz <[email protected]>
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Date: Wed, 23 Apr 2025 10:46:14 -0700
Message-ID: <CAOYmi+=cs+gDTAH0L+3JzpRLeHPOXDQxu7MOfsbjah9SkAP_kw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CAOYmi+n9DHS_xUatuuspdC8tjtaMzY8P11Y9y5Fz+2pjikkL9g@mail.gmail.com>
<[email protected]>
<CAOYmi+=2cArQoSSRdAYwx2TBSHL5r0UhX28Q-5TP=0g-sxBXCA@mail.gmail.com>
<CAGECzQShbNtypPqabVv2eKJP=0Ejox=6f8k8G1E-2GN6Ag1kAA@mail.gmail.com>
<CAOYmi+=j9nLQFjQ8z0vyQmuhNMwsFbzvne_2S2pTbBGir4q6EQ@mail.gmail.com>
<[email protected]>
<CAOYmi+k9uN2OQ_sXjztZYPSpPbfGmkkv4yhtPhyjNQ6vy7SSfA@mail.gmail.com>
<[email protected]>
<CAOYmi+=WA4ZfyHWt+4=yFV7VAXQWvNKsn4R=3PwLd4GfmSTiBA@mail.gmail.com>
<[email protected]>
On Wed, Apr 23, 2025 at 9:38 AM Christoph Berg <[email protected]> wrote:
> > We could all agree to bump the second number in the filename whenever
> > there's an internal ABI change. That works from a technical
> > perspective, but it's hard to test and enforce and... just not forget.
>
> It's hopefully not harder than checking ABI compatibility of any other
> libpq change, just a different number. If that number is in the
> meson.build in the same directory, people should be able to connect
> the dots.
I think it is harder, simply because no one has to do it today, and
that change would sign them up to do it, forever, adding to the
backport checklist. It's one thing if there's a bunch of committers
who pile into the thread right now saying "yes, that's okay", but I
don't really feel comfortable making that decision for them right this
instant.
If we had robust ABI compatibility checks as part of the farm [1], I
think we could do that. Doesn't feel like an 18 thing, though.
> Btw, if we have that number, we might as well drop the MAJOR part as
> well... apt.pg.o is always shipping the latest libpq5, so major libpq
> upgrades while apps are running are going to happen. (But this is just
> once a year and much less problematic than minor upgrades and I'm not
> going to complain if MAJOR is kept.)
I don't want to introduce another testing matrix dimension if I can
avoid it. ("I have this bug where libpq.so.5.18 is using
libpq-oauth.so from PG20 and I had no idea it was doing that and the
problem went away when I restarted and...")
And the intent is for this to be temporary until we have a user-facing
API. If this is the solution we go with, I think it'd wise to prepare
for a -19 version of libpq-oauth, but I'm going to try my best to get
custom modules in ASAP. People are going to be annoyed that v1 of the
feature doesn't let them swap the flow for our utilities. Ideally they
only have to deal with that for a single major release.
Also: since the libpq-oauth-18 and libpq-oauth-19 packages can be
installed side-by-side safely, isn't the upgrade hazard significantly
diminished? (If a user uninstalls the previous libpq-oauth version
while they're still running that version of libpq in memory, _and_
they've somehow never used OAuth until right that instant... it's easy
enough for them to undo their mistake while the application is still
running.)
> > Or, I may still be able to thread the needle with a fuller lookup
> > table, and remove the dependency on libpq-int.h; it's just not going
> > to be incredibly pretty. Thinking...
>
> Don't overdesign it...
Oh, I agree... but my "minimal" ABI designs have all had corner cases
so far. I may need to just bite the bullet.
Are there any readers who feel like an internal ABI version for
`struct pg_conn`, bumped during breaking backports, would be
acceptable? (More definitively: are there any readers who would veto
that?) You're still signing up for delayed errors in the long-lived
client case, so it's not a magic bullet, but the breakage is easy to
see and it's not a crash. The client application "just" has to restart
after a libpq upgrade.
Thanks,
--Jacob
[1] https://www.postgresql.org/message-id/B142EE8A-5D38-48B9-A4BB-82D69A854B55%40justatheory.com
view thread (194+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
In-Reply-To: <CAOYmi+=cs+gDTAH0L+3JzpRLeHPOXDQxu7MOfsbjah9SkAP_kw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox