Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Date
Msg-id CAA4eK1Ks8KNfA8AXOfV5u8Xs9xvsHuc7rmnwb-pK7F45fViKXA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Tue, Jun 25, 2019 at 12:42 AM Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >> Ah, got it.  So it seems like the correct behavior might be for
> > >> ALTER SYSTEM to
> > >> (a) run through the whole file and remove any conflicting lines;
> > >> (b) append new setting at the end.
> >
> > > That is exactly the behavior for which I am arguing.  Stephen also
> > > wants a warning, but I disagree, because the warning is totally
> > > non-actionable.  It tells you that some tool, at some point in the
> > > past, did something bad. You can't do anything about that, and you
> > > wouldn't need to except for the arbitrary decision to label duplicate
> > > lines as bad in the first place.
> >
> > Agreed; there's no particular reason to consider the situation as wrong.
> > guc.c has always had the policy that dups are fine and the last one wins.
> > The very design of ALTER SYSTEM owes its workability to that policy, so
> > we can hardly say that A.S. should have a different policy internally.
> >

Both are similar but not sure if they are the same because in A.S we
are planning to remove the duplicate entries from file whereas I think
in other places that rule is used to just ignore the duplicates and
allow the last one to win.   Now, I think there is merit in giving
WARNING in this case as we are intentionally removing something which
user has added it.  However,  it is not clear what user is going to do
with that WARNING unless we have a system where we detect such a
situation, give WARNING and then allow the user to proceed in this
case with some option like FORCE.

> > The problem here is simply that ALTER SYSTEM is failing to consider the
> > possibility that there are dups in postgresql.auto.conf, and that seems
> > like little more than an oversight to be fixed.
> >
> > There's more than one way we could implement a fix, perhaps, but I don't
> > really see a reason to work harder than is sketched above.
>
> Why bother removing the duplicate lines?
>
> If ALTER SYSTEM should remove them, why shouldn't other tools?
>
> > (BTW, has anyone checked whether ALTER SYSTEM RESET is prepared to remove
> > multiple lines for the same var?)
>
> No, it doesn't handle that today either, as discussed earlier in this
> thread.
>

Right, it doesn't handle that today, but I think we can deal it along
with Alter System Set ...

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Implementing Incremental View Maintenance
Next
From: Alexander Korotkov
Date:
Subject: Re: SQL/JSON path issues/questions