Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Alexander Lakhin <exclusion@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Peter Eisentraut <peter@eisentraut.org>, Soumyadeep Chakraborty <soumyadeep2007@gmail.com>, Zhihong Yu <zyu@yugabyte.com>, pgsql-hackers@postgresql.org, Ashwin Agrawal <ashwinstar@gmail.com>, vanjared@vmware.com
Date: 2024-04-16T05:14:21Z
Lists: pgsql-hackers
On Mon, Apr 15, 2024 at 10:46:00AM +0900, Michael Paquier wrote: > There is no need for a catalog here to trigger the failure, and it > would have happened as long as a foreign table is used. The problem > introduced in 374c7a229042 fixed by e2395cdbe83a comes from a thinko > on my side, my apologies for that and the delay in replying. Thanks > for the extra fix done in 13b3b62746ec, Alvaro. While doing more tests with this feature, among other things, I've spotted an incorrect behavior with dump/restore with the handling of the GUC default_table_access_method when it comes to partitions. Imagine the following in database "a": CREATE TABLE parent_tab (id int) PARTITION BY RANGE (id); CREATE TABLE parent_tab_2 (id int) PARTITION BY RANGE (id) USING heap; CREATE TABLE parent_tab_3 (id int) PARTITION BY RANGE (id); This leads to the following in pg_class: =# SELECT relname, relam FROM pg_class WHERE oid > 16000; relname | relam --------------+------- parent_tab | 0 parent_tab_2 | 2 parent_tab_3 | 0 (3 rows) Now, let's do the following: $ createdb b $ pg_dump | psql b $ psql b =# SELECT relname, relam FROM pg_class WHERE oid > 16000; relname | relam --------------+------- parent_tab | 0 parent_tab_2 | 0 parent_tab_3 | 0 (3 rows) And parent_tab_2 would now rely on the default GUC when creating new partitions rather than enforce heap. It seems to me that we are going to extend the GUC default_table_access_method with a "default" mode to be able to force relam to 0 and make a difference with the non-0 case, in the same way as ALTER TABLE SET ACCESS METHOD DEFAULT. The thing is that, like tablespaces, we have to rely on a GUC and not a USING clause to be able to handle --no-table-access-method. An interesting point comes to what we should do for default_table_access_method set to "default" when dealing with something else than a partitioned table, where an error may be adapted. Still, I'm wondering if there are more flavors I lack imagination for. This requires more careful design work. Perhaps somebody has a good idea? -- Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add information about access method for partitioned relations in \dP+
- 978f38c771fb 18.0 landed
-
Fix dumps of partitioned tables with table AMs
- f46bee346c3b 17.0 landed
-
Don't use the pg_am system catalog in new test
- 13b3b62746ec 17.0 landed
-
ALTER TABLE: rework determination of access method ID
- e2395cdbe83a 17.0 landed
-
Allow specifying an access method for partitioned tables
- 374c7a229042 17.0 landed
-
Review wording on tablespaces w.r.t. partitioned tables
- ea299d782511 15.7 landed
- e6c4e01bf440 16.3 landed
- a0390f6ca6c7 17.0 landed
- 58efabdc0ce9 12.19 landed
- 520e7afa5732 13.15 landed
- 33bfbef1d60f 14.12 landed
-
Add support for DEFAULT in ALTER TABLE .. SET ACCESS METHOD
- d61a6cad6418 17.0 landed
-
Update comment of AlterTableCmd->name in parsenodes.h
- 4f8c1e7aaf11 17.0 landed