On Mon, Nov 20, 2017 at 2:56 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
>
> Fabrízio de Royes Mello <
fabriziomello@gmail.com> writes:
> > typedef enum
> > {
> > ClientBackendProcess = -1,
> > CheckerProcess = 0,
> > BootstrapProcess,
>
> Uh, why would you do that (start from -1)? It makes it impossible to
> build an array indexed by the enum, which might be useful --- converting
> enum values to strings is one obvious application. Breaks your
> "NUM_PROCTYPES" thing, too.
>
I agree... I just copy and paste AuxProcType with some kind of generalization.
> What I'd do is probably
>
> UnknownProcess = 0,
> PostmasterProc,
> StandaloneBackendProc,
> ClientBackendProc,
> BootstrapProc,
> ...
> NUM_PROCTYPES /* Must be last! */
>
> The value of reserving "UnknownProcess = 0" is that a freshly started
> process would be correctly not-identified if the variable starts out 0.
> (I'd be rather tempted to teach fork_process to reset it to 0 immediately
> after forking, too, so that postmaster children couldn't inadvertently
> retain the PostmasterProc setting.)
>
Makes sense...
> I'm not entirely sure whether standalone backends ought to get their
> own code, or whether it's better for them to share ClientBackendProc.
> It's something we'd have to work out as we went through the code
> making the patch. How many places would want to distinguish, versus
> how many would have to test for two values?
>
Maybe for the first version we use just "ClientBackendProc" and refactor all the code necessary to generalize AuxProcType. Then we can step into into. Seems reasonable?
> > extern ProcType MyProcType;
>
> "PGProcType", maybe? "ProcType" alone seems pretty generic.
> "ServerProcType" is another possibility for the typedef name,
> to emphasize that what we are classifying is the postmaster
> and its children.
>
"ServerProcType" seems a good name.
Due to some "Blackfriday" commitments I'll be able to work again with this patch on next week.
