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>, Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, rmt@lists.postgresql.org, Nathan Bossart <nathandbossart@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2026-06-16T20:58:04Z
Lists: pgsql-hackers
On Tue, Jun 16, 2026 at 1:12 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> If there is concern over the neatness of this (long term in the backbranches,
> for master it will be reverted as mentioned), I guess one option could be to
> introduce a new binary, oauth_curl_version, which only prints the version and
> exits instead oa adding a flag to an otherwise unrelated binary.  It would add
> a little compilation overhead though.

I considered that, but I think adding a second binary to the existing
Makefile is likely to result in build system churn (to get it to
behave like e.g. test_json_parser/Makefile). I can investigate that
path if you think it'd be more maintainable that way, but let's make
sure Tom's point below doesn't moot it:

On Tue, Jun 16, 2026 at 1:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I confirm that, with or without 0004, this fixes the oauth_validator
> failure on the machine where I saw that.

Thanks very much!

> However ... I don't love the plan of fixing this differently in v19
> and v20 just because of feature freeze.  Exposing more information
> for testing purposes isn't a user-visible feature IMO, so I would
> rather we go straight to 0004.

Fair enough. If the RMT is okay with this for 19, were you thinking
we'd also backpatch that code directly to 18?

--Jacob



Commits

  1. oauth: Skip call-count test for libcurl 8.20.0

  2. libpq-oauth: Print libcurl version with OAUTHDEBUG_UNSAFE_TRACE