Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Robert Haas (robertmhaas@gmail.com) wrote:
> there's a fairly generous but fixed-at-startup-time limit on how many
> segments you can have.  In practice I don't think this matters much,
> but it was a sobering reminder that the main shared memory segment,
> with all of its inflexibility, has important reliability properties
> that are hard to replicate in more dynamic scenarios.

Why wouldn't it be possible to have the same arrangment for
shared_buffers, where you have more entires than you 'need' at startup
but which then allows you to add more shared segments later?  I do see
that we would need an additional bit of indirection to handle that,
which might be too much overhead, but the concept seems possible.  Isn't
that more-or-less how the kernel handles dynamic memory..?

> Under the currently-proposed design, it can't be used to do any such
> thing.  It can only be used to modify some auto.conf file which lives
> in $PGDATA.  It's therefore no different from the ops perspective than
> ALTER DATABASE or ALTER USER - except that it allows all settings to
> be changed rather than only a subset.

Claiming that modifying a file *included from a file in /etc* doesn't
modify things under /etc is disingenuous, imv.
Thanks,
    Stephen