Hi,
On 2019-10-03 14:33:26 -0400, Mike Palmiotto wrote:
> > > +#ifdef EXEC_BACKEND
> > > + aux_fork->av[ac++] = pstrdup("--forkboot");
> > > + aux_fork->av[ac++] = NULL; /* filled in by postmaster_forkexec */
> > > +#endif
> >
> > What's the point of pstrdup()ing constant strings here? Afaict you're
> > not freeing them ever?
>
> The idea was supposed to be that the prep work lives up until the fork
> happens and then is freed en masse with the rest of the MemoryContext.
> Perhaps there was some oversight here. I'll revisit this and others in
> the next pass.
Well, two things:
1) That'd *NEVER* be more efficient that just referencing constant
strings. Unless you pfree() the variable, and there sometimes can be
constant, and sometimes non-constant strings, there is simply no
reason to ever pstrdup a constant string.
2) Which context are you talking about? Are you thinking of? A forked
process doing MemoryContextDelete(PostmasterContext); doesn't free
that memory in postmaster.
> > > @@ -58,4 +58,8 @@ extern pid_t fork_process(void);
> > > extern pid_t postmaster_forkexec(ForkProcData *fork_data);
> > > #endif
> > >
> > > +/* Hook for plugins to get control after a successful fork_process() */
> > > +typedef void (*ForkProcess_post_hook_type) ();
> > > +extern PGDLLIMPORT ForkProcess_post_hook_type ForkProcess_post_hook;
> > > +
> > > #endif /* FORK_PROCESS_H */
> > > --
> > > 2.23.0
> > >
> >
> > Why do we want libraries to allow to hook into processes like the
> > startup process etc?
>
> There are a number of OS-level process manipulations that this could
> afford you as an extension developer. For instance, you could roll
> your own seccomp implementation (to limit syscalls per-process-type,
> perhaps?), perform some setcap magic, or some other security-related
> magic.
Color me unconvinced.
Greetings,
Andres Freund