=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziome...@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.
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.)
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?
> 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.
regards, tom lane
