Michael Paquier <michael.paqu...@gmail.com> writes: > On Mon, Nov 20, 2017 at 12:11 PM, Tom Lane <t...@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