MIME-Version: 1.0
References: <Zt_ZVcW4NmPM9NRB@paquier.xyz> <20240910172712.e8.nmisch@google.com>
 <CA+Tgmoade_mRdZQHMub31Y9YKg5FpZzwvzYP35R8AVszoRGWcg@mail.gmail.com>
 <20240910205850.5d.nmisch@google.com> <CA+Tgmoa9t-ei=mNjyjdcXxQOY=r0PO-+ncHpryjLaFgV9Y0tyg@mail.gmail.com>
 <20240913145621.43.nmisch@google.com> <CAOYmi+kLzSWrDHZbJg8bWZ94oP_K98mkoEvetgupOBVoy5H_ag@mail.gmail.com>
 <ZysDL6JAGR7UyCA9@paquier.xyz> <Zyww1XGpE1hQa0s1@paquier.xyz>
 <CAOYmi+k7Mz5RmaeHKTEcOPSXBLzATD=ofOXS+JpHB8=-cNHR0Q@mail.gmail.com> <faesruozcdcg2aksscb3dcojy4gqjqsyaxfajkqzm4kozjowgm@nmjgrrvdax25>
In-Reply-To: <faesruozcdcg2aksscb3dcojy4gqjqsyaxfajkqzm4kozjowgm@nmjgrrvdax25>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Thu, 7 Nov 2024 10:44:25 -0800
Message-ID: <CAOYmi+kUkCkSV13-a0b0rwmtge_uZnPKQx-yLFQJdfoceWFH2g@mail.gmail.com>
Subject: Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>, Robert Haas <robertmhaas@gmail.com>, 
	Noah Misch <noah@leadboat.com>, Andrew Dunstan <andrew@dunslane.net>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>, 
	Euler Taveira <euler.taveira@enterprisedb.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2BkUkCkSV13-a0b0rwmtge_uZnPKQx-yLFQJdfoceWFH2g%40mail.gmail.com>
Precedence: bulk

On Thu, Nov 7, 2024 at 10:12=E2=80=AFAM Andres Freund <andres@anarazel.de> =
wrote:
> I don't understand why the pgstat_bestart()/pgstat_bestart_pre_auth() spl=
it
> makes sense. The latter is going to redo most of the work that the former
> did. What's the point of that?
>
> Why not have a new function that initializes just the missing additional
> information? Or for that matter, why not move most of what pgstat_bestart=
()
> does into pgstat_beinit()?

I talk about that up above [1]. I agree that this is all complicated
and fragile, but at the moment, I think splitting things apart is not
going to reduce the complexity in any way. I'm all ears for a
different approach, though (and it sounds like Michael is taking a
stab at it too).

> This doesn't really seem like it's actually using wait events to describe
> waits. The new wait events cover stuff like memory allocations etc, see
> e.g. pg_SSPI_make_upn().

I've also asked about the "scope" of the waits in the OP [2]. I can
move them downwards in the stack, if you'd prefer.

All of these are intended to cover parts of the code that can actually
hang, but for things like SSPI I'm just working off of inspection and
Win32 documentation. So if it's not actually true that some of these
call points can hang, let me know and I can remove them. (For the
particular example you called out, I'm just trying to cover both calls
to TranslateName() in a maintainable place. The documentation says
"TranslateName fails if it cannot bind to Active Directory on a domain
controller." which seemed pretty wait-worthy to me.)

> This isn't just pedantry - all the relevant code really needs to be rewri=
tten
> to allow the blocking to happen in an interruptible way, otherwise
> authentication timeout etc can't realiably work. Once that's done you can
> actually define useful wait events too.

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.

--Jacob

[1] https://www.postgresql.org/message-id/CAOYmi%2BkLzSWrDHZbJg8bWZ94oP_K98=
mkoEvetgupOBVoy5H_ag%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAOYmi%2B%3D60deN20WDyCoHCiecgivJ=
xr%3D98s7s7-C8SkXwrCfHXg%40mail.gmail.com