On Mon, Nov 20, 2017 at 2:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> =?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.
>

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.

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

Reply via email to