Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Ian Barwick <ian(dot)barwick(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Date: 2019-08-05 17:24:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Aug 5, 2019 at 12:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Perhaps as a future improvement, but it's not happening for v12,
> >> at least not unless you accept "use ALTER SYSTEM in a standalone
> >> backend" as a usable answer.
> > I'm not sure that would even work for the cases at issue ... because
> > we're talking about setting up recovery parameters, and wouldn't the
> > server run recovery before it got around to do anything with ALTER
> Yeah, good point. There are a lot of other cases where you really
> don't want system startup to happen, too. On the other hand,
> people have also opined that they want full error checking on
> the inserted values, and that seems out of reach with less than
> a full running system (mumble extensions mumble).

There have been ideas brought up about some way to provide "full
validation" but I, at least, don't recall seeing anyone actually say
that they *want* that- just different people suggesting that it could be

I agree that full validation is a pipe dream for this kind of system and
isn't what I was intending to suggest at any point.

> In the end, I think I don't buy Stephen's argument that there should
> be a one-size-fits-all answer. It seems entirely reasonable that
> we'll have more than one way to do it, because the constraints are
> different depending on what use-case you think about.

This doesn't seem to me, at least, to be an accurate representation of
my thoughts on this- there could be 15 different ways to modify the
file, but let's have a common set of code to provide those ways instead
of different code between the backend ALTER SYSTEM and the frontend
pg_basebackup (and if we put it in the common library that we already
have for sharing code between the backend and the frontend, and which we
make available for external tools, then those external tools could use
those methods in the same way that we do).

I'm happy to be told I'm wrong, but as far as I know, there's nothing in
appending to the file or removing duplicates that actually requires
validation of the values which are included in order to apply those
operations correctly.

I'm sure I'll be told again about how we can't do this for 12, and I do
appreciate that, but it's because we ignored these issues during
development that we're here and that's really just not something that's
acceptable in my view- we shouldn't be pushing features which have known
issues that we then have to fight about how to fix it at the last minute
and with the constraint that we can't make any big changes.



In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-08-05 17:29:35 Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Previous Message Andres Freund 2019-08-05 17:16:08 Re: Adding column "mem_usage" to view pg_prepared_statements