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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: virgile(dot)crevon(at)dassault-aviation(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16026: default_tablespace in postgresql.conf is used instead of the database's default.
Date: 2019-10-17 01:31:02
Message-ID: CA+hUKGKmCbmks-72zjioDQjs9q8QO7FR2GZ4TPhZ6M-E1wZpBw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-www

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).

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-10-17 05:40:57 Re: BUG #16049: log_line_prefix=%a and log_connections - application_name missing
Previous Message Thomas Munro 2019-10-17 01:07:51 Re: BUG #15726: parallel queries failed ERROR: invalid name syntax CONTEXT: parallel worker

Browse pgsql-www by date

  From Date Subject
Next Message Crevon Virgile 2019-10-17 09:23:10 RE: BUG #16026: default_tablespace in postgresql.conf is used instead of the database's default.
Previous Message Justin Pryzby 2019-10-13 23:05:59 Re: "Resend email" gave me a "does not exist" message