Re: [HACKERS] [PATCH] A hook for session start
От | Fabrízio de Royes Mello |
---|---|
Тема | Re: [HACKERS] [PATCH] A hook for session start |
Дата | |
Msg-id | CAFcNs+rLAOETt-AS02m40P6_uKO5snQTOCzcycdg9dGzMOMzWQ@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 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.)
>
>
> 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?
>
> 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.
>
> "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
--
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 по дате отправления: