Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
От | Justin Pryzby |
---|---|
Тема | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |
Дата | |
Msg-id | ZCJuW3GOfE/0eBjh@telsasoft.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |
Список | pgsql-hackers |
On Tue, Mar 28, 2023 at 09:13:10AM +0900, Michael Paquier wrote: > On Mon, Mar 20, 2023 at 09:30:50AM +0900, Michael Paquier wrote: > > Did you check dump and restore flows with partition > > trees and --no-table-access-method? Perhaps there should be > > some regression tests with partitioned tables? > > I was looking at the patch, and as I suspected the dumps generated > are forgetting to apply the AM to the partitioned tables. The patch said: + else if (RELKIND_HAS_TABLE_AM(relkind) || relkind == RELKIND_PARTITIONED_TABLE) pg_dump was missing a similar change that's conditional on RELKIND_HAS_TABLE_AM(). It looks like those are the only two places that need be be specially handled. I dug up my latest patch from 2021 and incorporated the changes from the 0001 patch here, and added a test case. I realized that one difference with tablespaces is that, as written, partitioned tables will *always* have an AM specified, and partitions will never use default_table_access_method. Is that what's intended ? Or do we need logic similar tablespaces, such that the relam of a partitioned table is set only if it differs from default_table_am ? -- Justin
Вложения
В списке pgsql-hackers по дате отправления: