Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Noah Misch <noah@leadboat.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Euler Taveira <euler.taveira@enterprisedb.com>
Date: 2024-07-08T21:09:21Z
Lists: pgsql-hackers
Attachments
- v2-0001-BackgroundPsql-handle-empty-query-results.patch (application/octet-stream) patch v2-0001
- v2-0002-Test-Cluster-let-background_psql-work-asynchronou.patch (application/octet-stream) patch v2-0002
- v2-0004-WIP-report-external-auth-calls-as-wait-events.patch (application/octet-stream) patch v2-0004
- v2-0003-pgstat-report-in-earlier-with-STATE_AUTHENTICATIN.patch (application/octet-stream) patch v2-0003
On Sun, Jun 30, 2024 at 10:48 AM Noah Misch <noah@leadboat.com> wrote: > That looks like a reasonable user experience. Is any field newly-nullable? Technically I think the answer is no, since backends such as walwriter already have null database and user fields. It's new for a client backend to have nulls there, though. > That said, it > may be more fruitful to arrange for authentication timeout to cut through PAM > etc. That seems mostly out of our hands -- the misbehaving modules are free to ignore our signals (and do). Is there another way to force the issue? > Hanging connection slots hurt even if they lack an xmin. Oh, would releasing the xmin not really move the needle, then? > I assume it > takes an immediate shutdown to fix them? That's my understanding, yeah. > > Would anyone like me to be more aggressive, and create a pgstat entry > > as soon as we have the opening transaction? Or... as soon as a > > connection is made? > > All else being equal, I'd like backends to have one before taking any lmgr > lock or snapshot. I can look at this for the next patchset version. > > I haven't decided how to test these patches. Seems like a potential > > use case for injection points, but I think I'd need to preload an > > injection library rather than using the existing extension. Does that > > seem like an okay way to go? > > Yes. I misunderstood how injection points worked. No preload module needed, so v2 adds a waitpoint and a test along with a couple of needed tweaks to BackgroundPsql. I think 0001 should probably be applied independently. Thanks, --Jacob
Commits
-
Fix race condition in TAP test 007_pre_auth
- e2080261cc8c 18.0 landed
-
Split pgstat_bestart() into three different routines
- c76db55c9085 18.0 landed
-
backport: Extend background_psql() to be able to start asynchronously
- 6af51bf05a6a 13.21 landed
- 7c07ab62aeb7 14.18 landed
- c0bc11aebb01 15.13 landed
- 6ab58d506bba 16.9 landed
- 49b6f4a02b23 17.5 landed
-
backport: Improve handling of empty query results in BackgroundPsql
- 3c562b58c20e 13.21 landed
- 3170aece14b8 14.18 landed
- f4b08ccb4ec8 15.13 landed
- fbfd38662f72 16.9 landed
- 31a242e90c88 17.5 landed
-
Improve handling of empty query results in BackgroundPsql::query()
- 70291a3c66ec 18.0 landed
-
Extend Cluster.pm's background_psql() to be able to start asynchronously
- ba08edb06545 18.0 landed
-
dblink: Replace WAIT_EVENT_EXTENSION with custom wait events
- c789f0f6cc5d 17.0 cited