Re: [HACKERS] [PATCH] A hook for session start

On Mon, Nov 20, 2017 at 1:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> > On Mon, Nov 20, 2017 at 12:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

> 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.
>

Do we need the notion of process types groups? If no the idea of generalize
AuxProcType seems better.

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello