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
> 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.
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. If you attempt to update the parameter
with ALTER SYSTEM, then the command complains. So it seems to me that
the user experience is inconsistent.
--
Michael
