Re: [oauth] Split and extend PGOAUTHDEBUG - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: [oauth] Split and extend PGOAUTHDEBUG
Date
Msg-id CAOYmi+kCYZ3YiOu+oSv1gVW6LXQaNg4BcEpskYizWgfV1z12kA@mail.gmail.com
Whole thread
In response to Re: [oauth] Split and extend PGOAUTHDEBUG  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: [oauth] Split and extend PGOAUTHDEBUG
Re: [oauth] Split and extend PGOAUTHDEBUG
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Do we still need MULE_INTERNAL?
Next
From: Tom Lane
Date:
Subject: Re: LLVM 22