public inbox for [email protected]  
help / color / mirror / Atom feed
From: Jacob Champion <[email protected]>
To: Andres Freund <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Noah Misch <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Euler Taveira <[email protected]>
Subject: Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
Date: Thu, 7 Nov 2024 12:11:46 -0800
Message-ID: <CAOYmi+neRXD5LKUthKDaGLfAzApoyvL4OJF-VffifdwyqTdxsQ@mail.gmail.com> (raw)
In-Reply-To: <wujfqghd2uucboqjgo2igtsedrfp7mbif7iavu52asvfr72fju@27jevcaoz555>
References: <CA+Tgmoade_mRdZQHMub31Y9YKg5FpZzwvzYP35R8AVszoRGWcg@mail.gmail.com>
	<[email protected]>
	<CA+Tgmoa9t-ei=mNjyjdcXxQOY=r0PO-+ncHpryjLaFgV9Y0tyg@mail.gmail.com>
	<[email protected]>
	<CAOYmi+kLzSWrDHZbJg8bWZ94oP_K98mkoEvetgupOBVoy5H_ag@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAOYmi+k7Mz5RmaeHKTEcOPSXBLzATD=ofOXS+JpHB8=-cNHR0Q@mail.gmail.com>
	<faesruozcdcg2aksscb3dcojy4gqjqsyaxfajkqzm4kozjowgm@nmjgrrvdax25>
	<CAOYmi+kUkCkSV13-a0b0rwmtge_uZnPKQx-yLFQJdfoceWFH2g@mail.gmail.com>
	<wujfqghd2uucboqjgo2igtsedrfp7mbif7iavu52asvfr72fju@27jevcaoz555>

On Thu, Nov 7, 2024 at 11:41 AM Andres Freund <[email protected]> wrote:
> I think the patch should not be merged as-is. It's just too ugly and fragile.

Understood; I'm trying to find a way forward, and I'm pointing out
that the alternatives I've tried seem to me to be _more_ fragile.

Are there any items in this list that you disagree with/are less
concerned about?

- the pre-auth step must always initialize the entire pgstat struct
- two-step initialization requires two PGSTAT_BEGIN_WRITE_ACTIVITY()
calls for _every_ backend
- two-step initialization requires us to couple against the order that
authentication information is being filled in (pre-auth, post-auth, or
both)

> I think it might make more sense to use pgstat_report_activity() or such here,
> rather than using wait events to describe something that's not a wait.

I'm not sure why you're saying these aren't waits. If pam_authenticate
is capable of hanging for hours and bringing down a production system,
is that not a "wait"?

> > I agree that would be amazing! I'm not about to tackle reliable
> > interrupts for all of the current blocking auth code for v18, though.
> > I'm just trying to make it observable when we do something that
> > blocks.
>
> Well, with that justification we could end up adding wait events for large
> swaths of code that might not actually ever wait.

If it were hypothetically useful to do so, would that be a problem?
I'm trying not to propose things that aren't actually useful.

--Jacob






view thread (19+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
  In-Reply-To: <CAOYmi+neRXD5LKUthKDaGLfAzApoyvL4OJF-VffifdwyqTdxsQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox