| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [oauth] Split and extend PGOAUTHDEBUG |
| Date: | 2026-03-31 23:50:19 |
| Message-ID: | CAOYmi+kCYZ3YiOu+oSv1gVW6LXQaNg4BcEpskYizWgfV1z12kA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| since-v2.nocfbot.diff | application/octet-stream | 25.6 KB |
| v3-0001-Split-PGOAUTHDEBUG-UNSAFE-into-multiple-options.patch | application/octet-stream | 19.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-31 23:55:11 | Re: LLVM 22 |
| Previous Message | Tatsuo Ishii | 2026-03-31 23:38:26 | Re: Do we still need MULE_INTERNAL? |