Re: pg_basebackup failure after setting default_table_access_method option
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Haribabu Kommi <kommi.haribabu@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-06T07:06:36Z
Lists: pgsql-hackers
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
Commits
-
Don't access catalogs to validate GUCs when not connected to a DB.
- 69f32206d7e5 9.4.23 landed
- 483b2d7ae173 9.5.18 landed
- b8607e15e0fa 9.6.14 landed
- 52ad5fc0a6c3 10.9 landed
- c0155601763a 11.4 landed
- fff2a7d7bd09 12.0 landed