Re: ALTER TABLE SET ACCESS METHOD on partitioned tables - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Date
Msg-id ZCUZLiCeXq4Im7OG@telsasoft.com
Whole thread Raw
In response to Re: ALTER TABLE SET ACCESS METHOD on partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
List pgsql-hackers
On Mon, Mar 27, 2023 at 11:34:36PM -0500, Justin Pryzby wrote:
> 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 ?

Actually .. I think it'd be a mistake if the relam needed to be
interpretted differently for partitioned tables than other relkinds.

I updated the patch to allow intermediate partitioned tables to inherit
relam from their parent.

Michael wrote:
> .. and there are quite more points to consider.

What more points ?  There's nothing that's been raised here.  In fact,
your message last week is the first comment since last June ..

-- 
Justin

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Doc: Rework contrib appendix -- informative titles, tweaked sentences
Next
From: Jeff Davis
Date:
Subject: Re: running logical replication as the subscription owner