Re: BUG #16026: default_tablespace in postgresql.conf is used instead of the database's default.

On Fri, Sep 27, 2019 at 1:36 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Fri, Sep 27, 2019 at 3:01 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > > 1- create a tablespace data (whereever you want it to be). Note that data
> > > is lowercase without quotation marks.
> > > 2- set default_tablespace='DATA' in postgresql.conf. Note this is un
> > > UPPERCASE.
> > > 3- reload conf.
> > > 4- create a database with default tablespace data (lowercase).
> > > 5- create a query that is using parallel (gather step) to seq scan.
> >
> > This is the same issue discussed in
> >
> > https://www.postgresql.org/message-id/flat/15726-6d67e4fa14f027b3%40postgresql.org
> >
> > I'm not sure why progress on that thread has come to a dead halt,
> > but in any case, the general opinion seems to be that all we're
> > going to do about it is improve the error reporting. Wrong values
> > in postgresql.conf aren't a well-supported or encouraged situation,
> > even if it seems to mostly work for default_tablespace.
>
> Erm, yeah. I will fix that early next week.

That has now been done, but it doesn't help at all in this case. It
was already pretty clear from the ERROR message here that the problem
was default_tablespace being set to an invalid value (which is ignored
in regular backend startup), so the new CONTEXT message just repeats
that information.

I wondered why we have to restore GUCs inside a transaction, anyway,
creating this difference in behaviour in parallel queries. We have to
do that after restoring libraries, in case they defined new GUCs, and
in commit 6c3c9d41 we decided that we should restore libraries in a
transaction to avoid breaking a bunch of extensions (though GUCs were
already restored inside a transaction before that commit).