Gurjeet Singh <gurj...@singh.im> writes:
> Startup scripts are not solely in the domain of packagers. End users
> can also be expected to develop/edit their own startup scripts.
> Providing it as GUC would have given end users both the peices, but
> with a compile-time option they have only one half of the solution;
> except if they go compile their own binaries, which forces them into
> being packagers.
I don't find that this argument holds any water at all. Anyone who's
developing their own start script can be expected to manage recompiling
Postgres.
Extra GUCs do not have zero cost, especially not ones that are as
complicated-to-explain as this would be.
I would also argue that there's a security issue with making it a GUC.
A non-root DBA should not have the authority to decide whether or not
postmaster child processes run with nonzero OOM adjustment; that decision
properly belongs to whoever has authorized the root-owned startup script
to change the adjustment in the first place. So seeing this as two
independent pieces is not only wrong but dangerous.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
