Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [oauth] Split and extend PGOAUTHDEBUG
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: 
 <CAOYmi+kCYZ3YiOu+oSv1gVW6LXQaNg4BcEpskYizWgfV1z12kA@mail.gmail.com>
Date: Wed, 1 Apr 2026 11:45:08 +0800
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <89B8BFC0-582F-4A59-97D3-1829EFA04E45@gmail.com>
References: 
 <CAN4CZFMmDZMH56O9vb_g7vHqAk8ryWFxBMV19C39PFghENg8kA@mail.gmail.com>
 <CAOYmi+k_et3yXpJ8op71-95j7OYg-kX5bWLgW9YTV_5G7f+O1A@mail.gmail.com>
 <CAOYmi+kivcSnazEJA=KWknd3azGYnU3mMq9SUvht5Zq74qNcYQ@mail.gmail.com>
 <CAN4CZFMKCB2OXPGW0R_hCSu4Gg==B7dBSrv6Mf-YuFcrUncADg@mail.gmail.com>
 <CAOYmi+kCYZ3YiOu+oSv1gVW6LXQaNg4BcEpskYizWgfV1z12kA@mail.gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/89B8BFC0-582F-4A59-97D3-1829EFA04E45%40gmail.com>
Precedence: bulk


> On Apr 1, 2026, at 07:50, Jacob Champion =
<jacob.champion@enterprisedb.com> wrote:
>=20
> On Tue, Mar 31, 2026 at 10:45=E2=80=AFAM Zsolt Parragi
> <zsolt.parragi@percona.com> wrote:
>> I didn't want to write "print-poll-counts" and "print-trace" as those
>> are just longer, while simply writing "plugin-errors" without print
>> also seemed wrong. Maybe it could be "plugin-debug" instead, that
>> sounds good even withour print?
>=20
> I like `plugin-errors`, actually -- "I want to debug these plugin
> errors." Adding -debug to the name doesn't seem great to me, since
> it's clear from the context that we're debugging.
>=20
> `dos-retry` still doesn't quite convey what we're doing...
> `dos-endpoint` maybe? `busy-loop`? The unsafe aspect is the resource
> consumption...
>=20
> To keep the brainstorming going, I chose the following for v3, but
> they're by no means settled:
>=20
> - http
> - trace
> - dos-endpoint
> - call-count
> - plugin-errors
>=20
>>> I have a sample patch locally for these suggestions, if you'd like.
>>=20
>> I can create a patch with these updates tomorrow, but if you already
>> have it, that might be easier/quicker.
>=20
> In the interest of time I've attached it as a single patch, but the
> range-diff is rough to read. If you'd like, I can split the code
> motion apart from the logical changes tomorrow, to see if it helps
> with review.
>=20
> --Jacob
> =
<since-v2.nocfbot.diff><v3-0001-Split-PGOAUTHDEBUG-UNSAFE-into-multiple-op=
tions.patch>


Looks like this patch helps reduce uninteresting debug logs. Overall, it =
looks good to me. I just have a couple of small comments.

1
```
+#define OAUTHDEBUG_UNSAFE_HTTP			(1<<0)
```

Since the flags are defined as uint32, does it make sense to define =
these flag constants as ((uint32) 1 << 0)?

2 oauth_get_debug_flags() reparses PGOAUTHDEBUG every time it is called, =
which feels a bit unnecessary. But I don't think this is a big deal, =
since these debug options should never be enabled in production.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/