pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18674: Partitioned table doesn't depend on access method it uses
8+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2024-10-28 49a23441ca bb584e8312 Fix dependency of partitioned table and table AM with CREATE TABLE .. USING
* BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-26 06:00 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 8+ messages in thread
From: PG Bug reporting form @ 2024-10-26 06:00 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: exclusion@gmail.com
The following bug has been logged on the website:
Bug reference: 18674
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 17.0
Operating system: Ubuntu 22.04
Description:
The following script:
CREATE ACCESS METHOD ham TYPE TABLE HANDLER heap_tableam_handler;
CREATE TABLE pt (a int) PARTITION BY LIST (a) USING ham;
DROP ACCESS METHOD ham;
ends successfully, with the access method dropped, though then:
CREATE TABLE tp1 PARTITION OF pt FOR VALUES IN (1);
fails with
ERROR: cache lookup failed for access method 16385
Whilst
CREATE TABLE t (a int) USING ham;
DROP ACCESS METHOD ham;
fails with
ERROR: cannot drop access method ham because other objects depend on it
DETAIL: table t depends on access method ham
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Reproduced starting from 374c7a229.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-27 07:53 Kirill Reshke <reshkekirill@gmail.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 8+ messages in thread
From: Kirill Reshke @ 2024-10-27 07:53 UTC (permalink / raw)
To: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Hi!
On Sat, 26 Oct 2024 at 19:27, PG Bug reporting form
<noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 18674
> Logged by: Alexander Lakhin
> Email address: exclusion@gmail.com
> PostgreSQL version: 17.0
> Operating system: Ubuntu 22.04
> Description:
>
> The following script:
> CREATE ACCESS METHOD ham TYPE TABLE HANDLER heap_tableam_handler;
> CREATE TABLE pt (a int) PARTITION BY LIST (a) USING ham;
> DROP ACCESS METHOD ham;
>
> ends successfully, with the access method dropped, though then:
> CREATE TABLE tp1 PARTITION OF pt FOR VALUES IN (1);
>
> fails with
> ERROR: cache lookup failed for access method 16385
>
> Whilst
> CREATE TABLE t (a int) USING ham;
> DROP ACCESS METHOD ham;
>
> fails with
> ERROR: cannot drop access method ham because other objects depend on it
> DETAIL: table t depends on access method ham
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
>
> Reproduced starting from 374c7a229.
>
Nice catch!
Did you dig into reasons? I did a little...
After looking closely at the DefineRelation workflow, I discovered
that it is `RelationBuildLocalRelation` responsibility to add
dependency between relation and its TAM. The bug arises from the fact
that RELKIND_HAS_TABLE_AM doesn't respect partitioned relations.
So, a trivial fix is attached.
Does it look good for you?
--
Best regards,
Kirill Reshke
Attachments:
v1-0001-Change-RELKIND_HAS_TABLE_AM-to-support-partitione.patch (application/octet-stream, 919B) download
From 490ef3f594c7d786ed4de3766bc94051cad0f13b Mon Sep 17 00:00:00 2001
From: reshke kirill <reshke@double.cloud>
Date: Sun, 27 Oct 2024 07:48:00 +0000
Subject: [PATCH v1] Change RELKIND_HAS_TABLE_AM to support partitioned tables
---
src/include/catalog/pg_class.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/include/catalog/pg_class.h b/src/include/catalog/pg_class.h
index 0fc2c093b0..e8da6ff9fb 100644
--- a/src/include/catalog/pg_class.h
+++ b/src/include/catalog/pg_class.h
@@ -224,7 +224,8 @@ MAKE_SYSCACHE(RELNAMENSP, pg_class_relname_nsp_index, 128);
* rd_tableam; hence, this is handled specially outside of this macro.
*/
#define RELKIND_HAS_TABLE_AM(relkind) \
- ((relkind) == RELKIND_RELATION || \
+ ((relkind) == RELKIND_RELATION || \
+ (relkind) == RELKIND_PARTITIONED_TABLE || \
(relkind) == RELKIND_TOASTVALUE || \
(relkind) == RELKIND_MATVIEW)
--
2.34.1
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-27 20:23 Kirill Reshke <reshkekirill@gmail.com>
parent: Kirill Reshke <reshkekirill@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Kirill Reshke @ 2024-10-27 20:23 UTC (permalink / raw)
To: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sun, 27 Oct 2024 at 12:53, Kirill Reshke <reshkekirill@gmail.com> wrote:
>
> Hi!
>
> On Sat, 26 Oct 2024 at 19:27, PG Bug reporting form
> <noreply@postgresql.org> wrote:
> >
> > The following bug has been logged on the website:
> >
> > Bug reference: 18674
> > Logged by: Alexander Lakhin
> > Email address: exclusion@gmail.com
> > PostgreSQL version: 17.0
> > Operating system: Ubuntu 22.04
> > Description:
> >
> > The following script:
> > CREATE ACCESS METHOD ham TYPE TABLE HANDLER heap_tableam_handler;
> > CREATE TABLE pt (a int) PARTITION BY LIST (a) USING ham;
> > DROP ACCESS METHOD ham;
> >
> > ends successfully, with the access method dropped, though then:
> > CREATE TABLE tp1 PARTITION OF pt FOR VALUES IN (1);
> >
> > fails with
> > ERROR: cache lookup failed for access method 16385
> >
> > Whilst
> > CREATE TABLE t (a int) USING ham;
> > DROP ACCESS METHOD ham;
> >
> > fails with
> > ERROR: cannot drop access method ham because other objects depend on it
> > DETAIL: table t depends on access method ham
> > HINT: Use DROP ... CASCADE to drop the dependent objects too.
> >
> > Reproduced starting from 374c7a229.
> >
>
> Nice catch!
>
> Did you dig into reasons? I did a little...
>
> After looking closely at the DefineRelation workflow, I discovered
> that it is `RelationBuildLocalRelation` responsibility to add
> dependency between relation and its TAM. The bug arises from the fact
> that RELKIND_HAS_TABLE_AM doesn't respect partitioned relations.
> So, a trivial fix is attached.
>
> Does it look good for you?
>
> --
> Best regards,
> Kirill Reshke
As mentioned by Alexander off-list, v1 patch actually fails in a lot
of regression tests... My bad.
Seems that simply changing RELKIND_HAS_TABLE_AM marco is too invasive.
However, I will make another try. In v2 version, regression tests
still fail, i will adjust them, if patching this way is the right
approach to fix the problem..
script provided by Alexander:
CREATE ACCESS METHOD ham TYPE TABLE HANDLER heap_tableam_handler;
CREATE TABLE pt (a int) PARTITION BY LIST (a) USING ham;
DROP ACCESS METHOD ham;
now gives the correct output.
--
Best regards,
Kirill Reshke
Attachments:
v2-0001-Change-RELKIND_HAS_TABLE_AM-to-support-partitione.patch (application/octet-stream, 4.4K) download
From 81db8df7b012211685b1851106acf3db83df4c4d Mon Sep 17 00:00:00 2001
From: reshke kirill <reshke@double.cloud>
Date: Sun, 27 Oct 2024 07:48:00 +0000
Subject: [PATCH v2] Change RELKIND_HAS_TABLE_AM to support partitioned tables
---
src/backend/commands/tablecmds.c | 7 +++++--
src/backend/optimizer/util/plancat.c | 2 +-
src/backend/storage/buffer/bufmgr.c | 2 +-
src/backend/utils/cache/relcache.c | 2 +-
src/bin/pg_dump/pg_dump.c | 3 +--
src/include/catalog/pg_class.h | 1 +
6 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index e14bc0c054..c76294e6cb 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -979,10 +979,10 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
*/
if (stmt->accessMethod != NULL)
{
- Assert(RELKIND_HAS_TABLE_AM(relkind) || relkind == RELKIND_PARTITIONED_TABLE);
+ Assert(RELKIND_HAS_TABLE_AM(relkind));
accessMethodId = get_table_am_oid(stmt->accessMethod, false);
}
- else if (RELKIND_HAS_TABLE_AM(relkind) || relkind == RELKIND_PARTITIONED_TABLE)
+ else if (RELKIND_HAS_TABLE_AM(relkind))
{
if (stmt->partbound)
{
@@ -15029,6 +15029,9 @@ ATExecSetAccessMethodNoStorage(Relation rel, Oid newAccessMethodId)
/* Update the pg_class row. */
oldAccessMethodId = rd_rel->relam;
+ if (!OidIsValid(newAccessMethodId))
+ newAccessMethodId = get_table_am_oid(default_table_access_method, false);
+
rd_rel->relam = newAccessMethodId;
/* Leave if no update required */
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index b913f91ff0..b8e3d9f5bd 100644
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -1072,7 +1072,7 @@ estimate_rel_size(Relation rel, int32 *attr_widths,
BlockNumber relallvisible;
double density;
- if (RELKIND_HAS_TABLE_AM(rel->rd_rel->relkind))
+ if (RELKIND_HAS_TABLE_AM(rel->rd_rel->relkind) && rel->rd_rel->relkind != RELKIND_PARTITIONED_TABLE)
{
table_relation_estimate_size(rel, attr_widths, pages, tuples,
allvisfrac);
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 0f02bf62fa..1c18df7b80 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -3922,7 +3922,7 @@ FlushBuffer(BufferDesc *buf, SMgrRelation reln, IOObject io_object,
BlockNumber
RelationGetNumberOfBlocksInFork(Relation relation, ForkNumber forkNum)
{
- if (RELKIND_HAS_TABLE_AM(relation->rd_rel->relkind))
+ if (RELKIND_HAS_TABLE_AM(relation->rd_rel->relkind) && relation->rd_rel->relkind != RELKIND_PARTITIONED_TABLE)
{
/*
* Not every table AM uses BLCKSZ wide fixed size blocks. Therefore
diff --git a/src/backend/utils/cache/relcache.c b/src/backend/utils/cache/relcache.c
index c326f687eb..feb90c5ee7 100644
--- a/src/backend/utils/cache/relcache.c
+++ b/src/backend/utils/cache/relcache.c
@@ -3863,7 +3863,7 @@ RelationSetNewRelfilenumber(Relation relation, char persistence)
newrlocator = relation->rd_locator;
newrlocator.relNumber = newrelfilenumber;
- if (RELKIND_HAS_TABLE_AM(relation->rd_rel->relkind))
+ if (RELKIND_HAS_TABLE_AM(relation->rd_rel->relkind) && relation->rd_rel->relkind != RELKIND_PARTITIONED_TABLE)
{
table_relation_set_new_filelocator(relation, &newrlocator,
persistence,
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 1b47c388ce..665fb4c27a 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -16573,8 +16573,7 @@ dumpTableSchema(Archive *fout, const TableInfo *tbinfo)
if (RELKIND_HAS_TABLESPACE(tbinfo->relkind))
tablespace = tbinfo->reltablespace;
- if (RELKIND_HAS_TABLE_AM(tbinfo->relkind) ||
- tbinfo->relkind == RELKIND_PARTITIONED_TABLE)
+ if (RELKIND_HAS_TABLE_AM(tbinfo->relkind))
tableam = tbinfo->amname;
ArchiveEntry(fout, tbinfo->dobj.catId, tbinfo->dobj.dumpId,
diff --git a/src/include/catalog/pg_class.h b/src/include/catalog/pg_class.h
index 0fc2c093b0..66b8748e3e 100644
--- a/src/include/catalog/pg_class.h
+++ b/src/include/catalog/pg_class.h
@@ -225,6 +225,7 @@ MAKE_SYSCACHE(RELNAMENSP, pg_class_relname_nsp_index, 128);
*/
#define RELKIND_HAS_TABLE_AM(relkind) \
((relkind) == RELKIND_RELATION || \
+ (relkind) == RELKIND_PARTITIONED_TABLE || \
(relkind) == RELKIND_TOASTVALUE || \
(relkind) == RELKIND_MATVIEW)
--
2.34.1
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-28 07:23 Michael Paquier <michael@paquier.xyz>
parent: Kirill Reshke <reshkekirill@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Michael Paquier @ 2024-10-28 07:23 UTC (permalink / raw)
To: Kirill Reshke <reshkekirill@gmail.com>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Mon, Oct 28, 2024 at 01:23:23AM +0500, Kirill Reshke wrote:
> Seems that simply changing RELKIND_HAS_TABLE_AM marco is too invasive.
> However, I will make another try. In v2 version, regression tests
> still fail, i will adjust them, if patching this way is the right
> approach to fix the problem..
>
> script provided by Alexander:
> CREATE ACCESS METHOD ham TYPE TABLE HANDLER heap_tableam_handler;
> CREATE TABLE pt (a int) PARTITION BY LIST (a) USING ham;
> DROP ACCESS METHOD ham;
#define RELKIND_HAS_TABLE_AM(relkind) \
((relkind) == RELKIND_RELATION || \
+ (relkind) == RELKIND_PARTITIONED_TABLE || \
(relkind) == RELKIND_TOASTVALUE || \
(relkind) == RELKIND_MATVIEW)
This is an incorrect approach to the problem. RELKIND_HAS_TABLE_AM()
should be true only for relkinds that have rd_tableam set in their
relcache entries. However, you are breaking the original promise of
this macro because it is not set (and should not be set) for
partitioned tables as these have no physical presence on disk.
pg_class.relam is just a reference to use when creating partitions on
it. Note the comment in pg_class.h explaining the case of partitioned
tables.
Using an ALTER TABLE .. SET ACCESS METHOD on the partitioned table and
attempting a DROP ACCESS METHOD would fail. We are missing a normal
dependency entry in pg_depend for your sequence of commands between
the new partitioned table with the USING clause and its access method
set.
The path of adding the dependency between an AM and a table/matview is
heap_create_with_catalog() when these are defined. We can just expand
that for partitioned tables and simply fix the problem. Attached is a
patch to do that, with tests around create_am.sql based on USING
checking the contents of pg_depend.
--
Michael
Attachments:
0001-Fix-dependency-of-partitioned-table-and-its-table-AM.patch (text/x-diff, 3.1K) download
From 3bdc73cb92633cf1651d4c7e30691ac13809ef91 Mon Sep 17 00:00:00 2001
From: Michael Paquier <michael@paquier.xyz>
Date: Mon, 28 Oct 2024 16:11:49 +0900
Subject: [PATCH] Fix dependency of partitioned table and its table AM under
USING
---
src/backend/catalog/heap.c | 3 ++-
src/test/regress/expected/create_am.out | 16 ++++++++++++++++
src/test/regress/sql/create_am.sql | 12 ++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/heap.c
index 0078a12f26..c815019241 100644
--- a/src/backend/catalog/heap.c
+++ b/src/backend/catalog/heap.c
@@ -1473,7 +1473,8 @@ heap_create_with_catalog(const char *relname,
* No need to add an explicit dependency for the toast table, as the
* main table depends on it.
*/
- if (RELKIND_HAS_TABLE_AM(relkind) && relkind != RELKIND_TOASTVALUE)
+ if ((RELKIND_HAS_TABLE_AM(relkind) && relkind != RELKIND_TOASTVALUE) ||
+ relkind == RELKIND_PARTITIONED_TABLE)
{
ObjectAddressSet(referenced, AccessMethodRelationId, accessmtd);
add_exact_object_address(&referenced, addrs);
diff --git a/src/test/regress/expected/create_am.out b/src/test/regress/expected/create_am.out
index 35d4cf1d46..08a3eec142 100644
--- a/src/test/regress/expected/create_am.out
+++ b/src/test/regress/expected/create_am.out
@@ -343,6 +343,22 @@ ALTER MATERIALIZED VIEW heapmv SET ACCESS METHOD heap, SET ACCESS METHOD heap2;
ERROR: cannot have multiple SET ACCESS METHOD subcommands
DROP MATERIALIZED VIEW heapmv;
DROP TABLE heaptable;
+-- Partitioned table with USING
+BEGIN;
+CREATE TABLE am_partitioned(x INT, y INT) PARTITION BY hash (x) USING heap2;
+SELECT pg_describe_object(classid, objid, objsubid) AS obj,
+ pg_describe_object(refclassid, refobjid, refobjsubid) as refobj
+ FROM pg_depend, pg_am
+ WHERE pg_depend.refclassid = 'pg_am'::regclass
+ AND pg_am.oid = pg_depend.refobjid
+ AND pg_depend.objid = 'am_partitioned'::regclass;
+ obj | refobj
+----------------------+---------------------
+ table am_partitioned | access method heap2
+(1 row)
+
+DROP TABLE am_partitioned;
+COMMIT;
-- Partition hierarchies with access methods
BEGIN;
SET LOCAL default_table_access_method = 'heap';
diff --git a/src/test/regress/sql/create_am.sql b/src/test/regress/sql/create_am.sql
index 825aed325e..c43637227e 100644
--- a/src/test/regress/sql/create_am.sql
+++ b/src/test/regress/sql/create_am.sql
@@ -217,6 +217,18 @@ ALTER MATERIALIZED VIEW heapmv SET ACCESS METHOD heap, SET ACCESS METHOD heap2;
DROP MATERIALIZED VIEW heapmv;
DROP TABLE heaptable;
+-- Partitioned table with USING
+BEGIN;
+CREATE TABLE am_partitioned(x INT, y INT) PARTITION BY hash (x) USING heap2;
+SELECT pg_describe_object(classid, objid, objsubid) AS obj,
+ pg_describe_object(refclassid, refobjid, refobjsubid) as refobj
+ FROM pg_depend, pg_am
+ WHERE pg_depend.refclassid = 'pg_am'::regclass
+ AND pg_am.oid = pg_depend.refobjid
+ AND pg_depend.objid = 'am_partitioned'::regclass;
+DROP TABLE am_partitioned;
+COMMIT;
+
-- Partition hierarchies with access methods
BEGIN;
SET LOCAL default_table_access_method = 'heap';
--
2.45.2
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-28 08:00 Alexander Lakhin <exclusion@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 8+ messages in thread
From: Alexander Lakhin @ 2024-10-28 08:00 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Kirill Reshke <reshkekirill@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
Hello Michael and Kirill,
28.10.2024 10:23, Michael Paquier wrote:
> The path of adding the dependency between an AM and a table/matview is
> heap_create_with_catalog() when these are defined. We can just expand
> that for partitioned tables and simply fix the problem. Attached is a
> patch to do that, with tests around create_am.sql based on USING
> checking the contents of pg_depend.
0001-Fix-dependency....patch works for me, but while testing, I've also
observed another questionable behavior:
CREATE ACCESS METHOD heap2 TYPE TABLE HANDLER heap_tableam_handler;
SET default_table_access_method = heap2;
CREATE TABLE pt (a int) PARTITION BY LIST (a);
\d+ pt
doesn't show heap2 as access method for the table.
Shouldn't default_table_access_method affect partitioned tables?
Best regards.
Alexander
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-28 11:49 Junwang Zhao <zhjwpku@gmail.com>
parent: Alexander Lakhin <exclusion@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Junwang Zhao @ 2024-10-28 11:49 UTC (permalink / raw)
To: Alexander Lakhin <exclusion@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Kirill Reshke <reshkekirill@gmail.com>; pgsql-bugs@lists.postgresql.org
On Mon, Oct 28, 2024 at 4:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
>
> Hello Michael and Kirill,
>
> 28.10.2024 10:23, Michael Paquier wrote:
> > The path of adding the dependency between an AM and a table/matview is
> > heap_create_with_catalog() when these are defined. We can just expand
> > that for partitioned tables and simply fix the problem. Attached is a
> > patch to do that, with tests around create_am.sql based on USING
> > checking the contents of pg_depend.
>
> 0001-Fix-dependency....patch works for me, but while testing, I've also
> observed another questionable behavior:
> CREATE ACCESS METHOD heap2 TYPE TABLE HANDLER heap_tableam_handler;
> SET default_table_access_method = heap2;
> CREATE TABLE pt (a int) PARTITION BY LIST (a);
> \d+ pt
>
> doesn't show heap2 as access method for the table.
>
> Shouldn't default_table_access_method affect partitioned tables?
I think `default_table_access_method` should not affect partitioned tables,
the partition's access_method will be default_table_access_method as
wanted.
But if it affects partitioned tables, then the partitions will always
inherit the access method of the partitioned table.
You can try the following if you want it to affect partitioned tables:
inline patch 1: src/backend/commands/tablecmds.c (+0/-0 lines) download inline-1.patch
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 1ccc80087c..434e82ab14 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -973,7 +973,7 @@ DefineRelation(CreateStmt *stmt, char relkind, Oid ownerId,
accessMethodId =
get_rel_relam(linitial_oid(inheritOids));
}
- if (RELKIND_HAS_TABLE_AM(relkind) &&
!OidIsValid(accessMethodId))
+ if (!OidIsValid(accessMethodId))
accessMethodId =
get_table_am_oid(default_table_access_method, false);
}
>
> Best regards.
> Alexander
>
>
--
Regards
Junwang Zhao
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-28 22:48 Michael Paquier <michael@paquier.xyz>
parent: Junwang Zhao <zhjwpku@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Michael Paquier @ 2024-10-28 22:48 UTC (permalink / raw)
To: Junwang Zhao <zhjwpku@gmail.com>; +Cc: Alexander Lakhin <exclusion@gmail.com>; Kirill Reshke <reshkekirill@gmail.com>; pgsql-bugs@lists.postgresql.org
On Mon, Oct 28, 2024 at 07:49:54PM +0800, Junwang Zhao wrote:
> I think `default_table_access_method` should not affect partitioned tables,
> the partition's access_method will be default_table_access_method as
> wanted.
>
> But if it affects partitioned tables, then the partitions will always
> inherit the access method of the partitioned table.
Yes. default_table_access_method not affecting partitioned tables is
something that has been discussed on the thread that dealt with this
feature.
The point is for pg_class.relam == 0, which is a backward-compatible
way of telling that the partitions attached to the partitioned table
should use as AM what default_table_access_method is set to when a
partition is created.
relam for a partitioned table would be set only if there is a USING
clause in the CREATE TABLE or for ALTER TABLE SET ACCESS METHOD (the new
DEFAULT keyword can be used to set relam back to 0). There is a
pretty good chunk of SQL in create_am.sql for all these interactions
between the GUC, multiple levels of partitionining and partitions
attached. See around "Partition hierarchies with access methods".
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18674: Partitioned table doesn't depend on access method it uses
@ 2024-10-29 02:17 Michael Paquier <michael@paquier.xyz>
parent: Michael Paquier <michael@paquier.xyz>
0 siblings, 0 replies; 8+ messages in thread
From: Michael Paquier @ 2024-10-29 02:17 UTC (permalink / raw)
To: Junwang Zhao <zhjwpku@gmail.com>; +Cc: Alexander Lakhin <exclusion@gmail.com>; Kirill Reshke <reshkekirill@gmail.com>; pgsql-bugs@lists.postgresql.org
On Tue, Oct 29, 2024 at 07:48:30AM +0900, Michael Paquier wrote:
> Yes. default_table_access_method not affecting partitioned tables is
> something that has been discussed on the thread that dealt with this
> feature.
Anyway, I've fixed this issue with 49a23441ca7f and backpatched it
down to 17. Thanks for the report, Alexander.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2024-10-29 02:17 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-10-26 06:00 BUG #18674: Partitioned table doesn't depend on access method it uses PG Bug reporting form <noreply@postgresql.org>
2024-10-27 07:53 ` Kirill Reshke <reshkekirill@gmail.com>
2024-10-27 20:23 ` Kirill Reshke <reshkekirill@gmail.com>
2024-10-28 07:23 ` Michael Paquier <michael@paquier.xyz>
2024-10-28 08:00 ` Alexander Lakhin <exclusion@gmail.com>
2024-10-28 11:49 ` Junwang Zhao <zhjwpku@gmail.com>
2024-10-28 22:48 ` Michael Paquier <michael@paquier.xyz>
2024-10-29 02:17 ` Michael Paquier <michael@paquier.xyz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox