Re: pg_basebackup failure after setting default_table_access_method option
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>,
Haribabu Kommi <kommi.haribabu@gmail.com>, vignesh C <vignesh21@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-06-08T16:45:55Z
Lists: pgsql-hackers
> On Sat, Jun 8, 2019 at 5:30 PM Andres Freund <andres@anarazel.de> wrote: > > On 2019-06-08 16:03:09 +0200, Dmitry Dolgov wrote: > > > On Thu, Jun 6, 2019 at 9:06 AM Michael Paquier <michael@paquier.xyz> wrote: > > > 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. > > > > is correct, but doesn't it leave the room for some problems in the future with > > a wrong assumptions about correctness of default_table_access_method? > > What do you mean by that? I didn't have any particular problem in mind, just an abstract and probably wrong observation. One more observation is that this > Every single use of default_table_access_method (and similarly > default_tablespace) has to check the value, because it could be outdated / > not checked due to wrong context. for default_tablespace clearly expressed in GetDefaultTablespace function (if you see something like that, obviously you better use it), but there is nothing like similar for default_table_access_method so one have to keep it in mind (although of course it's not a problem so far, since it's being used in only one place).
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