public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Tom Lane <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Alexander Lakhin <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Soumyadeep Chakraborty <[email protected]>
Cc: Zhihong Yu <[email protected]>
Cc: [email protected]
Cc: Ashwin Agrawal <[email protected]>
Cc: [email protected]
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Date: Tue, 16 Apr 2024 14:14:21 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<ZglExpzL9w0MtBWf@pryzbyj2023>
<[email protected]>
<[email protected]>
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox