Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 16 Apr 2024 14:14:21 +0900
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
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Message-ID: <Zh4JLSvvtQgBJZkZ@paquier.xyz>
References: <202403281558.xk5pgf7ur3dq@alvherre.pgsql>
 <f3e61e27-19d0-5e40-3eb2-53282fa0532a@gmail.com>
 <ZglExpzL9w0MtBWf@pryzbyj2023>
 <1464385.1712034366@sss.pgh.pa.us>
 <ZhyG2JS2z6I6Kf7a@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="hD3ZOqMUo7BoyBD2"
Content-Disposition: inline
In-Reply-To: <ZhyG2JS2z6I6Kf7a@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/Zh4JLSvvtQgBJZkZ%40paquier.xyz>
Precedence: bulk


--hD3ZOqMUo7BoyBD2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
=3D# SELECT relname, relam FROM pg_class WHERE oid > 16000;
   relname    | relam=20
--------------+-------
 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
=3D# SELECT relname, relam FROM pg_class WHERE oid > 16000;
   relname    | relam=20
--------------+-------
 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

--hD3ZOqMUo7BoyBD2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmYeCS0ACgkQnvQgOdby
QH1sJg/+NRZ9lkM8HWafXiDuOw3a7hS/vCTUIacJAHiMMOIkaaaIKf2lqiA58flq
2Dv+D6krd30Emw9xurfEgxoTTqTEbHDpVtgL5LDqfVq+VgkZCNH23VfM8wuuqMUD
QqTc8ulFbcO3rTFqU2TPX054q2nPNb9Xl+VCaHBMMg/tY4dHtHsIR3gvBj29fJo3
63P98kPxMX2c1Wa3G3YAjQ12GlFAJAecFd0Q6g94Av2x3rb718nh78aH77V0Zb/u
OCU2hKOw4y2YHizmGHmO+DClCq3YA9/62lpLTU2EF9AcAv2HRdYFfiVmxT3AXjK1
Pc29cL0hRshY6zREh3G8n8Zy3Tg2iyNVQyik4cOE6ITCTXLVCNasLjCVEUTf+ivz
Vc2eF/gDhFSgtVak2FMjhUOiQ4/ZI2+U6WDesXgFcCPUfL407HDEHeJhti3hLcff
XxLYjnDN+ZW0HEcUhAojJ9oXpzIxCtZegmJzoEOUYeQ+9ArRSUcg9mBT2ITcRZIM
O68VX9Uh56fqACzPXXRUtg/OW3GoYQExQXFO2tzQN25VOhce183nbNT11gv/Kio2
wxLshO2V0R05MyC81QY81TCI7ONvGi/O9I+hJy0HpwSPMbGvg7pDNAzc12nZyhGs
mP/Zp81dk/ni1FO+lw4dBvjdPGyDqFxBelCha+/mLcfsGKKGyA8=
=kqdk
-----END PGP SIGNATURE-----

--hD3ZOqMUo7BoyBD2--