| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [oauth] Split and extend PGOAUTHDEBUG |
| Date: | 2026-04-01 03:45:08 |
| Message-ID: | 89B8BFC0-582F-4A59-97D3-1829EFA04E45@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Apr 1, 2026, at 07:50, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> On Tue, Mar 31, 2026 at 10:45 AM Zsolt Parragi
> <zsolt(dot)parragi(at)percona(dot)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?
>
> 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.
>
> `dos-retry` still doesn't quite convey what we're doing...
> `dos-endpoint` maybe? `busy-loop`? The unsafe aspect is the resource
> consumption...
>
> To keep the brainstorming going, I chose the following for v3, but
> they're by no means settled:
>
> - http
> - trace
> - dos-endpoint
> - call-count
> - plugin-errors
>
>>> I have a sample patch locally for these suggestions, if you'd like.
>>
>> I can create a patch with these updates tomorrow, but if you already
>> have it, that might be easier/quicker.
>
> 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.
>
> --Jacob
> <since-v2.nocfbot.diff><v3-0001-Split-PGOAUTHDEBUG-UNSAFE-into-multiple-options.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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2026-04-01 03:48:08 | Redundant/mis-use of _(x) gettext macro? |
| Previous Message | Bertrand Drouvot | 2026-04-01 03:44:44 | Re: Avoid multiple SetLatch() calls in procsignal_sigusr1_handler() |