Hi,
FWIW, I think you've just put the final nail in the coffin of this
patch by raising the barriers unreasonably high.
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > I agree that we need to do reasonable checks, like running GUC
> > validators, but we simply can't control the overall system state. And
> > it's not like this are errors that you couldn't get before. And we
> > should (that's something to improve on) report the relevant guc + file
> > in many cases.
>
> You could get the errors before, sure, but when you did, you could read
> the log output and go modify the *configuration files* (which things in
> $PGDATA are *not*) and fix it and get the system back online. If the
> files in $PGDATA have to be modified to get the system online then they
> are configuration files and should be in /etc.
That doesn't seem to be a logical consequence to me.
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.
> > We can improve the detection rate of problems after some real world
> > experience. Don't make this unneccesarily complex.
>
> Actually, putting it out there as "this can be used to modify anything
> and means you can trivially make PG unstartable" is actually the wrong
> move to make, imv. Consider that, to deal with the issues caused, we'd
> have to *remove* things from being modifyable through this function.
> That's a whole lot harder to do from a backward-compatibility view than
> adding things later as we improve PG to be able to still come up enough
> to be useful even with configuration issues.
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. Starting from DELETE FROM pg_class, ending with
COPYing files into the datadir. This is a database, not a children's
toy, and the feature *is* superuser only.
Anyway, I don't see much point arguing this further.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services