Re: [oauth] Increased CPU usage during device flow with libcurl 8.20.0
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Daniel Gustafsson <daniel@yesql.se>
Date: 2026-06-15T22:56:52Z
Lists: pgsql-hackers
Attachments
- 0001-oauth_validator-Print-captured-stderr-after-call-cou.patch (application/octet-stream) patch 0001
- 0002-libpq-oauth-Print-libcurl-version-with-OAUTHDEBUG_UN.patch (application/octet-stream) patch 0002
- 0003-oauth-Skip-call-count-test-for-libcurl-8.20.0.patch (application/octet-stream) patch 0003
On Mon, Jun 15, 2026 at 12:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jacob Champion <jacob.champion@enterprisedb.com> writes: > > So that just leaves what to do about the current test failures. My > > current idea is to just skip the test if the curl binary reports that > > specific minor version. > > Seems like a good solution. We don't know how long such curl > binaries will persist in the wild. Cool. Unfortunately, I immediately ran into an obvious-in-retrospect problem: the Homebrew libcurl we're linked against is not what you see when you type `curl --version` at the command line, and I don't think we record the runtime version of libcurl anywhere today. I've attached a solution that should work well for PG20, but I don't feel as good about it for 19 (or a backport to 18). I need to switch to a different context for today, but tomorrow I'll try to find a solution that touches only the test code. Thanks, --Jacob
Commits
-
oauth: Skip call-count test for libcurl 8.20.0
- c5c35fd7c55c 18 (unreleased) landed
- fd5ea2e9e37c 19 (unreleased) landed
-
libpq-oauth: Print libcurl version with OAUTHDEBUG_UNSAFE_TRACE
- 357e4d64f871 18 (unreleased) landed
- 4bd477dcc619 19 (unreleased) landed