On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Huh? Lots of people install PostgreSQL via, say, RPMs, but may still want to change their startup script locally. I don't think those users should have to give up the benefits of RPM packaging because they want a different oom_adj value. Then they have to be responsible for updating the packages every time there's a new minor release, instead of just typing 'yum update'. That's a LOT of extra work. > Extra GUCs do not have zero cost, especially not ones that are as > complicated-to-explain as this would be. NOT having them isn't free either. > 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. I think the only possible issue is if the DBA doesn't even have shell access. If he doesn't have root but does have shell access, he could have recompiled anyway - it's just more work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
