Re: exposing wait events for non-backends (was: Tracking wait event for latches)
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
From: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>,
Craig Ringer <craig@2ndquadrant.com>, Kevin Grittner <kgrittn@gmail.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-03-21T13:37:08Z
Lists: pgsql-hackers
Attachments
- 0001-Infra-to-expose-all-backend-processes-in-pg_stat_get.patch (application/x-download) patch 0001
- 0002-Expose-stats-for-all-backends.patch (application/x-download) patch 0002
- 0003-Add-backend_type-column-in-pg_stat_get_activity.patch (application/x-download) patch 0003
On Tue, Mar 21, 2017 at 10:52 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
Thank you for the review.
> Unfortunately this is true only for background workers that connect to
> a database. And this would break for bgworkers that do not do that.
> The point to fix is here:
> + if (MyBackendId != InvalidBackendId)
> + {
> [...]
> + else if (IsBackgroundWorker)
> + {
> + /* bgworker */
> + beentry->st_backendType = B_BG_WORKER;
> + }
> Your code is assuming that a bgworker will always be setting
> MyBackendId which is not necessarily true, and you would trigger the
> assertion down:
> Assert(MyAuxProcType != NotAnAuxProcess);
> So you need to rely on IsBackgroundWorker in priority I think. I would
> suggest as well to give up calling pgstat_bestart() in
> BackgroundWorkerInitializeConnection[ByOid] and let the workers do
> this work by themselves. This gives more flexibility. You would need
> to update the logical replication worker and worker_spi for that as
> well.
We reserve a slot for each possible BackendId, plus one for each
possible auxiliary process type. For a non-auxiliary process,
BackendId is used to refer the backend status in PgBackendStatus
array. So, a bgworker without any BackendId can't initialize its'
entry in PgBackendStatus array. In simple terms, it will not be shown
in pg_stat_activity. I've added some comments regarding this in
pgstat_bestart().
And, any bgworker having valid BackendId will have either a valid
userid or BOOTSTRAP_SUPERUSERID.
> If you want to test this configuration, feel free to use this background worker:
> https://github.com/michaelpq/pg_plugins/tree/master/hello_world
> This just prints an entry to the logs every 10s, and does not connect
> to any database. Adding a call to pgstat_bestart() in hello_main
> triggers the assertion.
>
In this case, pgstat_bestart() shouldn't be called from this module as
the spawned bgworker will have invalid BackendId. By the way, thanks
for sharing the repo link. Found a lot of interesting things to
explore and learn. :)
>>> @@ -808,6 +836,7 @@ pg_stat_get_activity(PG_FUNCTION_ARGS)
>>> nulls[12] = true;
>>> nulls[13] = true;
>>> nulls[14] = true;
>>> + nulls[23] = true;
>>> }
>>> That's not possible to have backend_type set as NULL, no?
>>
>> Yes, backend_type can't be null. But, I'm not sure whether it should
>> be visible to a user with insufficient privileges. Anyway, I've made
>> it visible to all user for now.
>>
>> Please find the updated patches in the attachment.
>
> Yeah, hiding it may make sense...
Modified.
> /* The autovacuum launcher is done here */
> if (IsAutoVacuumLauncherProcess())
> + {
> return;
> + }
> Unnecessary noise here.
>
Fixed.
> Except for the two issues pointed out in this email, I am pretty cool
> with this patch. Nice work.
Thank you. :)
Please find the updated patches.
--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com
Commits
-
Show more processes in pg_stat_activity.
- fc70a4b0df38 10.0 landed