On Thu, Nov 7, 2024 at 11:41 AM Andres Freund <and...@anarazel.de> 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
