Re: [oauth] Split and extend PGOAUTHDEBUG
| От | Chao Li |
|---|---|
| Тема | Re: [oauth] Split and extend PGOAUTHDEBUG |
| Дата | |
| Msg-id | 89B8BFC0-582F-4A59-97D3-1829EFA04E45@gmail.com обсуждение |
| Ответ на | Re: [oauth] Split and extend PGOAUTHDEBUG (Jacob Champion <jacob.champion@enterprisedb.com>) |
| Ответы |
Re: [oauth] Split and extend PGOAUTHDEBUG
|
| Список | pgsql-hackers |
> On Apr 1, 2026, at 07:50, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > On Tue, Mar 31, 2026 at 10:45 AM 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? > > 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 smallcomments. 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 thinkthis 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/
В списке pgsql-hackers по дате отправления: