* Robert Haas (robertmh...@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
signature.asc
Description: Digital signature