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
