Re: [HACKERS] [PATCH] A hook for session start
От | Fabrízio de Royes Mello |
---|---|
Тема | Re: [HACKERS] [PATCH] A hook for session start |
Дата | |
Msg-id | CAFcNs+rHHx3LhBrmYLcqzNpQXPZFzSGgSFCYewJ2=5vmpaQBxA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] A hook for session start (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] A hook for session start
|
Список | pgsql-hackers |
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?
> 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
> 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
В списке pgsql-hackers по дате отправления: