Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
От | Jacob Champion |
---|---|
Тема | Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible |
Дата | |
Msg-id | CAOYmi+=+py0pJSKCvZSXZbA9CRxc=OtLXx90BRDj-Rdx2f2WDg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [PATCH] pg_stat_activity: make slow/hanging authentication more visible
|
Список | pgsql-hackers |
On Tue, Mar 4, 2025 at 8:45 PM Michael Paquier <michael@paquier.xyz> wrote: > What this is telling us is that we should change the query scanning > pg_stat_activity for a PID of a backend in 'starting' state so as we > also check the wait_event init-pre-auth, as this is reported when > using injection point waits. The attached should be enough to take > care of this race condition. That's a lot easier than the rabbit hole I was running down; thank you. > - "SELECT pid FROM pg_stat_activity WHERE state = 'starting';"); > + qq{SELECT pid FROM pg_stat_activity > + WHERE state = 'starting' and wait_event = 'init-pre-auth';}); I had intended for this part of the patch to also wait for client backends only (see v8-0001, 001_ssltests.pl), but I must have misapplied it. (The ssltests change was lost completely when that file was dropped from the set.) So while we're at it, should we add a `backend_type = 'client backend'` filter to stop that from flaking in the future? That would further align this query with the wait_for_event() implementation. Thanks, --Jacob
В списке pgsql-hackers по дате отправления: