On Mon, Nov 20, 2017 at 1:38 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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. >
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