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
