Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Date
Msg-id CA+TgmoYzukS2pWqXcw72B7aQ8r=mzZHF8p30G1kLAkcy2=kp-w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Responses Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Tue, Mar 14, 2017 at 7:22 AM, Kuntal Ghosh
<kuntalghosh.2007@gmail.com> wrote:
> I do have extended localBackendStatusTable with slots for non-backend
> processes. But, I've renamed it as localProcStatusTable since it
> includes all processes. I'll keep the variable name as
> localBackendStatusTable in the updated patch to avoid any confusion.
> I've extended BackendStatusArray to store auxiliary processes.
> Backends use slots indexed in the range from 1 to MaxBackends
> (inclusive), so we use MaxBackends + AuxProcType + 1 as the index of
> the slot for an auxiliary process.

I think the subject of this the thread, for which I'm probably to
blame, is bad terminology.  The processes we're talking about exposing
in pg_stat_activity here are really backends, too, I think.  They're
just ... special backends.  So I would tend to avoid any backend ->
process type of renaming.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] logical replication access control patches
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Add amcheck extension to contrib.