Michael Paquier <michael.paquier@gmail.com> writes:
> On Mon, Nov 20, 2017 at 12:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The stuff related to AuxProcType is in miscadmin.h, so one possibility
>> is to put the new enum there. But I could see inventing a whole new
>> header for this, "utils/proctype.h" or so.
> I am on board for a new, dedicated, header, miscadmin.h having already
> a lot of things. So this API could just be located in its own file say
> in src/backend/utils/misc?
Maybe I'm missing something, but it seems like the only .c infrastructure
the header would need is a backend-global variable "MyProcType" or so.
That could perfectly well live in globals.c.
The model I'm imagining at the moment is that we generalize AuxProcType
to classify all PG processes not just "aux" processes. The new header
would need to contain the enum typedef, an extern for the global
variable, and a bunch of test macros --- we'd move AmBootstrapProcess(),
IsAutoVacuumWorkerProcess(), and the rest of those into that header.
Whatever else pgstat is doing could probably stay in pgstat.c. The
other infrastructure needed is for each kind of process to set MyProcType
as soon as possible during process start, but that's inherently something
not very centralizable.
Alternatively, we keep AuxProcType as-is, and invent a new enum that
classifies everything else, with one of its values being "AuxProc".
I'm not sure that sort of two-level scheme has any advantage, but
it's hard to tell for sure without doing the work to make a patch.
regards, tom lane
