On Mon, Nov 20, 2017 at 1:38 AM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
>
> 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.
>
Something like it ??
src/include/utils/proctype.h
typedef enum
{
ClientBackendProcess = -1,
CheckerProcess = 0,
BootstrapProcess,
StartupProcess,
BgWriterProcess,
CheckpointerProcess,
WalWriterProcess,
WalReceiverProcess,
WalSenderProcess,
AutovacuumLauncherProcess,
AutovacuumWorkerProcess,
BackgroundWorkerProcess,
StatsCollectorProcess,
ArchiverProcess,
LogicalReplicationLauncherProcess,
LogicalReplicationWorkerProcess,
LoggerProcess,
NUM_PROCTYPES /* Must be last! */
} ProcType;
extern ProcType MyProcType;
Should "MyProcType" be defined in globals.c, right?
