Re: pg_basebackup failure after setting default_table_access_method option

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_basebackup failure after setting default_table_access_method option
Date: 2019-06-08 15:26:07
Message-ID: 20190608152607.fuizlvwybaoxfvpv@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-06-06 16:06:36 +0900, Michael Paquier wrote:
> On Thu, Jun 06, 2019 at 11:19:48AM +1000, Haribabu Kommi wrote:
> > Thanks for the details steps to reproduce the bug, I am also able to
> > reproduce the problem.
>
> This way is even more simple, no need for zheap to be around:
> =# create access method heap2 TYPE table HANDLER heap_tableam_handler;
> CREATE ACCESS METHOD
> And then:
> PGOPTIONS="-c default_table_access_method=heap2" psql "replication=1"
> psql: error: could not connect to server: FATAL: cannot read pg_class
> without having selected a database

Yea, need to fix that.

> > Thanks for the patch and it fixes the problem.
>
> I was wondering if we actually need at all a catalog lookup at this
> stage, simplifying get_table_am_oid() on the way so as we always
> throw an error (its missing_ok is here to allow a proper error in the
> GUC context). The table AM lookup happens only when creating a table,
> so we could just get a failure when attempting to create a table with
> this incorrect value.

I think that'd be a bad plan. We check other such GUCs,
e.g. default_tablespace where this behaviour has been copied from, even
if not bulletproof.

> Actually, when updating a value and reloading and/or restarting the
> server, it is possible to easily get in a state where we have an
> invalid table AM parameter stored in the GUC, which is what the
> callback is here to avoid.

We have plenty other callbacks that aren't bulletproof, so I don't think
this is really something we should / can change in isolation here.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-06-08 15:30:47 Re: pg_basebackup failure after setting default_table_access_method option
Previous Message Guillaume Lelarge 2019-06-08 14:23:55 Re: Quick doc typo fix