* Andres Freund (and...@2ndquadrant.com) wrote: > FWIW, I think you've just put the final nail in the coffin of this > patch by raising the barriers unreasonably high.
For my 2c, I don't think it's an unreasonable idea to actually
*consider* what options are available through this mechanism rather than
just presuming that it's a good idea to be able to modify anything,
including things that you wouldn't be able to fix after a restart w/o
hacking around in $PGDATA.
I also don't believe that limiting the set of options which can be
modified through this system is a particularly difficult thing to
implement.
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-08-01 21:06:49 -0400, Stephen Frost wrote:
> > > Even trying to do this completely will guarantee that this patch will
> > > never, ever, suceed. There simply is no way to reliably detect problems
> > > that have complex interactions with the rest of the system.
> >
> > The patch will never be able to completely remove the need for external
> > config files, without changes to PG to deal with these conditions
> > better.
>
> That's not the goal of the patch as far as I understand it.
The point above is that we will always need some amount of external
config file and, as such, we should probably consider which items should
really only be set in the *config* files and which can be set in either
place.
> I think this chain of argument doesn't have much for it. There are
> litteraly dozens of ways to break postgres from SQL which we don't even
> try to defend against.
This is a strawman. An admin doing "DELETE FROM pg_class;" or using
COPY to overwrite files in PG's data dir and doing "ALTER SYSTEM SET
shared_buffers = '2GB';", "ALTER SYSTEM SET port = 123;" or even "ALTER
SYSTEM SET data_directory = '/new/path/for/db';" (how would doing that
even make sense..?) are not nearly the same. On the flip side, there's
not nearly as much risk around allowing log_line_prefix and friends to
be set through ALTER SYSTEM SET because it's pretty unlikely that such
a misconfiguration would cause PG to not start.
Thanks,
Stephen
signature.asc
Description: Digital signature
