Re: unclear OAuth error message

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: unclear OAuth error message
Date: 2026-03-27 17:01:59
Message-ID: CAOYmi+mxcvtJ9QJhxd4SbYHk=+L9r3VrK0xJ1DsM+H3pFFUtGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 23, 2026 at 2:21 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> Isn't including the detail for both the warning and the fatal error
> still overly verbose?

I'm not too worried about verbosity for an internal error situation;
users shouldn't see it. If they do, I don't mind being very loud about
whose fault it is.

(I'm also influenced by some recent support work on clusters that have
huge log volumes. If someone is focused on the internal error, they
should be able to see at a glance what caused that error, and if
someone is focused on the authentication failure, they should be able
to see at a glance what caused that. The more logs you have to
correlate in a "help! no one can log in" panic situation, the less
likely you are to succeed.)

> Shouldn't the oauth code include a sanity check to ensure validators
> return no error_detail on success instead of silently ignoring it?

IMO, no. I don't want error_detail to add semantics to the API, just
descriptive power. Plus, I think a design that sets a possible error
message before entering a complex operation, knowing that it will be
ignored on success, is perfectly valid. libpq-oauth, and to a lesser
extent libpq, make use of that pattern.

--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-03-27 17:03:11 Re: unclear OAuth error message
Previous Message Jeff Davis 2026-03-27 17:01:48 Re: Expanding HOT updates for expression and partial indexes