pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
24+ messages / 7 participants
[nested] [flat]
* BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
@ 2024-06-09 06:00 PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-19 04:29 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-27 13:54 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 3 replies; 24+ messages in thread
From: PG Bug reporting form @ 2024-06-09 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: 18500
Logged by: Alexander Lakhin
Email address: exclusion@gmail.com
PostgreSQL version: 17beta1
Operating system: Ubuntu 22.04
Description:
The following script:
CREATE TABLE t (a integer) PARTITION BY RANGE (a);
CREATE TABLE tp (a integer PRIMARY KEY);
ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
CREATE UNIQUE INDEX t_a_idx ON t (a);
ALTER INDEX t_a_idx ATTACH PARTITION tp_pkey;
\d+ t*
ALTER TABLE t DETACH PARTITION tp;
triggers an assertion failure as below:
...
Partitioned index "public.t_a_idx"
Column | Type | Key? | Definition | Storage | Stats target
--------+---------+------+------------+---------+--------------
a | integer | yes | a | plain |
unique, btree, for table "public.t"
Partitions: tp_pkey
Access method: btree
...
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
TRAP: failed Assert("constrForm->coninhcount == 0"), File:
"pg_constraint.c", Line: 873, PID: 3272276
...
#5 0x000055b26dc9b76f in ExceptionalCondition (
conditionName=conditionName@entry=0x55b26dd2d254
"constrForm->coninhcount == 0",
fileName=fileName@entry=0x55b26dd2d230 "pg_constraint.c",
lineNumber=lineNumber@entry=873) at assert.c:66
#6 0x000055b26d8687d7 in ConstraintSetParentConstraint
(childConstrId=16392, parentConstrId=parentConstrId@entry=0,
childTableId=childTableId@entry=0) at pg_constraint.c:873
#7 0x000055b26d9361c7 in DetachPartitionFinalize
(rel=rel@entry=0x7f84a051d4b8, partRel=partRel@entry=0x7f84a0514428,
concurrent=concurrent@entry=false,
defaultPartOid=defaultPartOid@entry=0) at tablecmds.c:19306
#8 0x000055b26d94449a in ATExecDetachPartition
(wqueue=wqueue@entry=0x7fff8d338780, tab=tab@entry=0x55b26fcd6f90,
rel=rel@entry=0x7f84a051d4b8, name=<optimized out>, concurrent=false) at
tablecmds.c:19140
#9 0x000055b26d944fe0 in ATExecCmd (wqueue=wqueue@entry=0x7fff8d338780,
tab=tab@entry=0x55b26fcd6f90,
cmd=<optimized out>, lockmode=lockmode@entry=8,
cur_pass=cur_pass@entry=AT_PASS_MISC,
context=context@entry=0x7fff8d338890) at tablecmds.c:5515
...
Without asserts enabled, DETACH executed with no error.
Reproduced on REL_11_STABLE .. master.
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
@ 2024-06-10 07:50 ` Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2 siblings, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2024-06-10 07:50 UTC (permalink / raw)
To: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sun, Jun 09, 2024 at 06:00:00AM +0000, PG Bug reporting form wrote:
> CREATE TABLE t (a integer) PARTITION BY RANGE (a);
> CREATE TABLE tp (a integer PRIMARY KEY);
> ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
>
> CREATE UNIQUE INDEX t_a_idx ON t (a);
> ALTER INDEX t_a_idx ATTACH PARTITION tp_pkey;
>
> \d+ t*
> ALTER TABLE t DETACH PARTITION tp;
>
> TRAP: failed Assert("constrForm->coninhcount == 0"), File:
> "pg_constraint.c", Line: 873, PID: 3272276
> ...
> #5 0x000055b26dc9b76f in ExceptionalCondition (
> conditionName=conditionName@entry=0x55b26dd2d254
> "constrForm->coninhcount == 0",
> fileName=fileName@entry=0x55b26dd2d230 "pg_constraint.c",
> lineNumber=lineNumber@entry=873) at assert.c:66
This DDL sequence completely breaks partitioned tree indexes AFAIU.
As reported, the inheritance count is wrong. Anyway, from what I can
see, I think that the ATTACH PARTITION is wrong and it should issue an
error because this is attempting to attach an index used by a
constraint to a partitioned index which is *not* related to a
constraint in the parent. I am pretty sure that more chirurgy around
AttachPartitionEnsureIndexes() with lookups at pg_constraint are
required here.
It's a bit disappointing that this would not work to make sure that
the index used by the partitioned table is on a primary key, ensuring
a consistent partition tree for the whole, with all indexes used in
the pk:
=# alter table t add primary key using index t_a_idx ;
ERROR: 0A000: ALTER TABLE / ADD CONSTRAINT USING INDEX is not
supported on partitioned tables
LOCATION: ATExecAddIndexConstraint, tablecmds.c:9259
This sequence, however, is fine:
CREATE TABLE t (a integer) PARTITION BY RANGE (a);
CREATE TABLE tp (a integer PRIMARY KEY);
ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
alter table t add primary key (a);
ALTER TABLE t DETACH PARTITION tp;
Note that before the DETACH we have this index tree, with a consistent
coninhcount:
=# select * from pg_partition_tree('t_pkey');
relid | parentrelid | isleaf | level
---------+-------------+--------+-------
t_pkey | null | f | 0
tp_pkey | t_pkey | t | 1
(2 rows)
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../ZmawLsFY3JStl85w@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
@ 2024-06-12 05:49 ` Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
0 siblings, 1 reply; 24+ messages in thread
From: Tender Wang @ 2024-06-12 05:49 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Hi, all
I found another crash case as below:
CREATE TABLE t (a integer) PARTITION BY RANGE (a);
CREATE TABLE tp (a integer PRIMARY KEY);
CREATE UNIQUE INDEX t_a_idx ON t (a);
ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
ALTER TABLE t DETACH PARTITION tp;
If index of parent is not created by adding constraint, it will trigger
assert fail.
I look through the DetachPartitionFinalize(). The logic of detach indexes
finds a pg_inherits tuple,
then it goes to detach the constraint between parent and child. But in
AttachPartitionEnsureIndexes(),
it check whether constraint of parent is valid or not. If it is valid, then
the code will build constraint
connection between parent and child.
I think we can do this check in DetachPartitionFinalize(). We skip to
detach the constraint if parent actually
does not have one. I try to fix theses issue in attached patch.
--
Tender Wang
OpenPie: https://en.openpie.com/
Attachments:
[application/octet-stream] v1-0001-Fix-assert-failure-when-detach-partition.patch (6.6K, ../../CAHewXNnZhGT1eM58-=5MQQ=moJ4hjqd3aDscxPSmB+SzwN3oUQ@mail.gmail.com/3-v1-0001-Fix-assert-failure-when-detach-partition.patch)
download | inline diff:
From 40d43781c41359d2fc834827db55d8edd39710cf Mon Sep 17 00:00:00 2001
From: Tender Wang <tndrwang@gmail.com>
Date: Wed, 12 Jun 2024 13:29:10 +0800
Subject: [PATCH v1] Fix assert failure when detach partition.
---
src/backend/catalog/pg_inherits.c | 26 ++++++++++++++++++++
src/backend/commands/tablecmds.c | 21 ++++++++++++++++
src/include/catalog/pg_inherits.h | 2 ++
src/test/regress/expected/partition_info.out | 13 ++++++++++
src/test/regress/sql/partition_info.sql | 15 +++++++++++
5 files changed, 77 insertions(+)
diff --git a/src/backend/catalog/pg_inherits.c b/src/backend/catalog/pg_inherits.c
index 836b4bfd89..c386863699 100644
--- a/src/backend/catalog/pg_inherits.c
+++ b/src/backend/catalog/pg_inherits.c
@@ -393,6 +393,32 @@ has_superclass(Oid relationId)
return result;
}
+/*
+ * get_superclass - returns this relation inherit tuple if it has
+ */
+HeapTuple
+get_superclass(Oid relationId)
+{
+ Relation catalog;
+ SysScanDesc scan;
+ ScanKeyData skey;
+ HeapTuple inhTup,
+ retval = NULL;
+
+ catalog = table_open(InheritsRelationId, AccessShareLock);
+ ScanKeyInit(&skey, Anum_pg_inherits_inhrelid, BTEqualStrategyNumber,
+ F_OIDEQ, ObjectIdGetDatum(relationId));
+ scan = systable_beginscan(catalog, InheritsRelidSeqnoIndexId, true,
+ NULL, 1, &skey);
+ inhTup = systable_getnext(scan);
+ if (HeapTupleIsValid(inhTup))
+ retval = heap_copytuple(inhTup);
+
+ systable_endscan(scan);
+ table_close(catalog, AccessShareLock);
+
+ return retval;
+}
/*
* Given two type OIDs, determine whether the first is a complex type
* (class type) that inherits from the second.
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 6adfd87614..a300676e14 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -19289,6 +19289,10 @@ DetachPartitionFinalize(Relation rel, Relation partRel, bool concurrent,
Oid idxid = lfirst_oid(cell);
Relation idx;
Oid constrOid;
+ HeapTuple parentTuple;
+ Oid parentIdxid;
+ Oid parentConstrOid;
+ Form_pg_inherits inhForm;
if (!has_superclass(idxid))
continue;
@@ -19296,15 +19300,32 @@ DetachPartitionFinalize(Relation rel, Relation partRel, bool concurrent,
Assert((IndexGetRelation(get_partition_parent(idxid, false), false) ==
RelationGetRelid(rel)));
+ /* Get inherit tuple */
+ parentTuple = get_superclass(idxid);
+ Assert(HeapTupleIsValid(parentTuple));
+ inhForm = (Form_pg_inherits) GETSTRUCT(parentTuple);
+ parentIdxid = inhForm->inhparent;
+
+ parentConstrOid = get_relation_idx_constraint_oid(RelationGetRelid(rel),
+ parentIdxid);
idx = index_open(idxid, AccessExclusiveLock);
IndexSetParentIndex(idx, InvalidOid);
+ /* Skip if there's no a constraint associated with parent index */
+ if (!OidIsValid(parentConstrOid))
+ {
+ heap_freetuple(parentTuple);
+ index_close(idx, NoLock);
+ continue;
+ }
+
/* If there's a constraint associated with the index, detach it too */
constrOid = get_relation_idx_constraint_oid(RelationGetRelid(partRel),
idxid);
if (OidIsValid(constrOid))
ConstraintSetParentConstraint(constrOid, InvalidOid, InvalidOid);
+ heap_freetuple(parentTuple);
index_close(idx, NoLock);
}
diff --git a/src/include/catalog/pg_inherits.h b/src/include/catalog/pg_inherits.h
index b3da78c24b..d8855a1733 100644
--- a/src/include/catalog/pg_inherits.h
+++ b/src/include/catalog/pg_inherits.h
@@ -18,6 +18,7 @@
#ifndef PG_INHERITS_H
#define PG_INHERITS_H
+#include "access/htup.h"
#include "catalog/genbki.h"
#include "catalog/pg_inherits_d.h"
@@ -56,6 +57,7 @@ extern List *find_all_inheritors(Oid parentrelId, LOCKMODE lockmode,
List **numparents);
extern bool has_subclass(Oid relationId);
extern bool has_superclass(Oid relationId);
+extern HeapTuple get_superclass(Oid relationId);
extern bool typeInheritsFrom(Oid subclassTypeId, Oid superclassTypeId);
extern void StoreSingleInheritance(Oid relationId, Oid parentOid,
int32 seqNumber);
diff --git a/src/test/regress/expected/partition_info.out b/src/test/regress/expected/partition_info.out
index 42b6bc77ca..3f689989b9 100644
--- a/src/test/regress/expected/partition_info.out
+++ b/src/test/regress/expected/partition_info.out
@@ -275,6 +275,19 @@ SELECT pg_partition_root('ptif_normal_table');
(1 row)
DROP TABLE ptif_normal_table;
+-- If parent index doesn't have a constraint tuple
+-- detach partition should not fail.
+CREATE TABLE pt_ind_t (a int) PARTITION BY RANGE (a);
+CREATE TABLE pt_ind_tp (a int PRIMARY KEY);
+ALTER TABLE pt_ind_t ATTACH PARTITION pt_ind_tp FOR VALUES FROM (0) TO (1000);
+CREATE UNIQUE INDEX pt_a_idx ON pt_ind_t (a);
+ALTER INDEX pt_a_idx ATTACH PARTITION pt_ind_tp_pkey;
+ALTER TABLE pt_ind_t DETACH PARTITION pt_ind_tp;
+CREATE TABLE pt_indx_t (a int) PARTITION BY RANGE (a);
+CREATE TABLE pt_indx_tp (a int PRIMARY KEY);
+CREATE UNIQUE INDEX ptx_a_idx ON pt_indx_t (a);
+ALTER TABLE pt_indx_t ATTACH PARTITION pt_indx_tp FOR VALUES FROM (0) TO (1000);
+ALTER TABLE pt_indx_t DETACH PARTITION pt_indx_tp;
-- Various partitioning-related functions return empty/NULL if passed relations
-- of types that cannot be part of a partition tree; for example, views,
-- materialized views, legacy inheritance children or parents, etc.
diff --git a/src/test/regress/sql/partition_info.sql b/src/test/regress/sql/partition_info.sql
index b5060bec7f..a36f8db562 100644
--- a/src/test/regress/sql/partition_info.sql
+++ b/src/test/regress/sql/partition_info.sql
@@ -105,6 +105,21 @@ SELECT * FROM pg_partition_ancestors('ptif_normal_table');
SELECT pg_partition_root('ptif_normal_table');
DROP TABLE ptif_normal_table;
+-- If parent index doesn't have a constraint tuple
+-- detach partition should not fail.
+CREATE TABLE pt_ind_t (a int) PARTITION BY RANGE (a);
+CREATE TABLE pt_ind_tp (a int PRIMARY KEY);
+ALTER TABLE pt_ind_t ATTACH PARTITION pt_ind_tp FOR VALUES FROM (0) TO (1000);
+CREATE UNIQUE INDEX pt_a_idx ON pt_ind_t (a);
+ALTER INDEX pt_a_idx ATTACH PARTITION pt_ind_tp_pkey;
+ALTER TABLE pt_ind_t DETACH PARTITION pt_ind_tp;
+
+CREATE TABLE pt_indx_t (a int) PARTITION BY RANGE (a);
+CREATE TABLE pt_indx_tp (a int PRIMARY KEY);
+CREATE UNIQUE INDEX ptx_a_idx ON pt_indx_t (a);
+ALTER TABLE pt_indx_t ATTACH PARTITION pt_indx_tp FOR VALUES FROM (0) TO (1000);
+ALTER TABLE pt_indx_t DETACH PARTITION pt_indx_tp;
+
-- Various partitioning-related functions return empty/NULL if passed relations
-- of types that cannot be part of a partition tree; for example, views,
-- materialized views, legacy inheritance children or parents, etc.
--
2.34.1
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
@ 2024-06-12 06:12 ` Michael Paquier <michael@paquier.xyz>
2024-06-12 06:44 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-27 18:41 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 3 replies; 24+ messages in thread
From: Michael Paquier @ 2024-06-12 06:12 UTC (permalink / raw)
To: Tender Wang <tndrwang@gmail.com>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Wed, Jun 12, 2024 at 01:49:32PM +0800, Tender Wang wrote:
> Hi, all
>
> I found another crash case as below:
> CREATE TABLE t (a integer) PARTITION BY RANGE (a);
> CREATE TABLE tp (a integer PRIMARY KEY);
> CREATE UNIQUE INDEX t_a_idx ON t (a);
> ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
> ALTER TABLE t DETACH PARTITION tp;
>
> If index of parent is not created by adding constraint, it will trigger
> assert fail.
The 4th command is I think incorrect to attach "t_a_idx" to "tp"'s
primary key index because "t" does not have an equivalent entry in
pg_constraint. So that does not address the actual issue.
> I look through the DetachPartitionFinalize(). The logic of detach indexes
> finds a pg_inherits tuple,
> then it goes to detach the constraint between parent and child. But in
> AttachPartitionEnsureIndexes(),
> it check whether constraint of parent is valid or not. If it is valid, then
> the code will build constraint
> connection between parent and child.
>
> I think we can do this check in DetachPartitionFinalize(). We skip to
> detach the constraint if parent actually
> does not have one. I try to fix theses issue in attached patch.
Are you sure that this is correct? This still makes "tp_pkey" a
partition of "t_a_idx" while the parent table "t" has no constraint
equivalent to "tp"'s primary key. It seems to me that the correct
answer in your command sequence is to *not* make "tp_pkey" a partition
of the partitioned index "t_a_idx", and leave it alone. Attaching
"tp_pkey" as a partition of "t_a_idx" is only OK as long as this index
is used in a constraint equivalent to "tp_pkey".
Having a PK on a partition while the parent does not have one is
covered by a regression test in indexing.sql (see "Constraint-related
indexes" and "primary key on child is okay").
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../Zmk8T4KtTjLCKR5C@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
@ 2024-06-12 06:44 ` Tender Wang <tndrwang@gmail.com>
2 siblings, 0 replies; 24+ messages in thread
From: Tender Wang @ 2024-06-12 06:44 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Michael Paquier <michael@paquier.xyz> 于2024年6月12日周三 14:12写道：
> On Wed, Jun 12, 2024 at 01:49:32PM +0800, Tender Wang wrote:
> > Hi, all
> >
> > I found another crash case as below:
> > CREATE TABLE t (a integer) PARTITION BY RANGE (a);
> > CREATE TABLE tp (a integer PRIMARY KEY);
> > CREATE UNIQUE INDEX t_a_idx ON t (a);
> > ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
> > ALTER TABLE t DETACH PARTITION tp;
> >
> > If index of parent is not created by adding constraint, it will trigger
> > assert fail.
>
> The 4th command is I think incorrect to attach "t_a_idx" to "tp"'s
> primary key index because "t" does not have an equivalent entry in
> pg_constraint. So that does not address the actual issue.
>
> > I look through the DetachPartitionFinalize(). The logic of detach indexes
> > finds a pg_inherits tuple,
> > then it goes to detach the constraint between parent and child. But in
> > AttachPartitionEnsureIndexes(),
> > it check whether constraint of parent is valid or not. If it is valid,
> then
> > the code will build constraint
> > connection between parent and child.
> >
> > I think we can do this check in DetachPartitionFinalize(). We skip to
> > detach the constraint if parent actually
> > does not have one. I try to fix theses issue in attached patch.
>
> Are you sure that this is correct? This still makes "tp_pkey" a
> partition of "t_a_idx" while the parent table "t" has no constraint
>
After IndexSetParentIndex(idx, InvalidOid); done, then we check the
constraint of parent is valid or not. "tp_pkey" will not inherited from
"t_a_idx".
> equivalent to "tp"'s primary key. It seems to me that the correct
> answer in your command sequence is to *not* make "tp_pkey" a partition
> of the partitioned index "t_a_idx", and leave it alone. Attaching
> "tp_pkey" as a partition of "t_a_idx" is only OK as long as this index
> is used in a constraint equivalent to "tp_pkey".
>
> Having a PK on a partition while the parent does not have one is
> covered by a regression test in indexing.sql (see "Constraint-related
> indexes" and "primary key on child is okay").
> --
> Michael
>
Michael, sorry for getting this email again. Last email forgot to cc others.
--
Tender Wang
OpenPie: https://en.openpie.com/
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
@ 2024-06-12 09:19 ` Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2 siblings, 1 reply; 24+ messages in thread
From: Tender Wang @ 2024-06-12 09:19 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Michael Paquier <michael@paquier.xyz> 于2024年6月12日周三 14:12写道：
> On Wed, Jun 12, 2024 at 01:49:32PM +0800, Tender Wang wrote:
> > Hi, all
> >
> > I found another crash case as below:
> > CREATE TABLE t (a integer) PARTITION BY RANGE (a);
> > CREATE TABLE tp (a integer PRIMARY KEY);
> > CREATE UNIQUE INDEX t_a_idx ON t (a);
> > ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
> > ALTER TABLE t DETACH PARTITION tp;
> >
> > If index of parent is not created by adding constraint, it will trigger
> > assert fail.
>
> The 4th command is I think incorrect to attach "t_a_idx" to "tp"'s
> primary key index because "t" does not have an equivalent entry in
> pg_constraint. So that does not address the actual issue.
>
> > I look through the DetachPartitionFinalize(). The logic of detach indexes
> > finds a pg_inherits tuple,
> > then it goes to detach the constraint between parent and child. But in
> > AttachPartitionEnsureIndexes(),
> > it check whether constraint of parent is valid or not. If it is valid,
> then
> > the code will build constraint
> > connection between parent and child.
> >
> > I think we can do this check in DetachPartitionFinalize(). We skip to
> > detach the constraint if parent actually
> > does not have one. I try to fix theses issue in attached patch.
>
> Are you sure that this is correct? This still makes "tp_pkey" a
> partition of "t_a_idx" while the parent table "t" has no constraint
> equivalent to "tp"'s primary key. It seems to me that the correct
> answer in your command sequence is to *not* make "tp_pkey" a partition
> of the partitioned index "t_a_idx", and leave it alone. Attaching
>
I think what you said above. I feel that we need that "tp_pkey" is a
partition
of the partitioned index "t_a_idx". For example, below statement:
test=# alter table tp drop constraint tp_pkey;
ERROR: cannot drop index tp_pkey because index t_a_idx requires it
HINT: You can drop index t_a_idx instead.
If "tp_pkey" is not a partition of "t_a_idx", the primary key "tp_pkey" can
be dropped.
"tp_pkey" as a partition of "t_a_idx" is only OK as long as this index
> is used in a constraint equivalent to "tp_pkey".
>
> Having a PK on a partition while the parent does not have one is
> covered by a regression test in indexing.sql (see "Constraint-related
> indexes" and "primary key on child is okay").
> --
> Michael
>
--
Tender Wang
OpenPie: https://en.openpie.com/
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
@ 2024-06-28 11:27 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 00:15 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-07-03 18:21 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 2 replies; 24+ messages in thread
From: Alvaro Herrera @ 2024-06-28 11:27 UTC (permalink / raw)
To: Tender Wang <tndrwang@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 2024-Jun-12, Tender Wang wrote:
> I think what you said above. I feel that we need that "tp_pkey" is a
> partition
> of the partitioned index "t_a_idx". For example, below statement:
>
> test=# alter table tp drop constraint tp_pkey;
> ERROR: cannot drop index tp_pkey because index t_a_idx requires it
> HINT: You can drop index t_a_idx instead.
>
> If "tp_pkey" is not a partition of "t_a_idx", the primary key "tp_pkey" can
> be dropped.
I guess you could also fix this by adding a PK constraint to the parent
table, so that the situation is consistent in the other direction.
Here's a proposed patch for master only. It turns all three situations
being reported into ereport(ERROR); in one case I have an XXX comment,
because we have an alternative when attaching a partition that already
has a PK to a partitioned table that has a non-PK index: just create a
separate index in the partition. But that would cause slowness, which
is probably undesirable. I'm inclined to just remove the XXX comment,
but if anyone has other thoughts, they are welcome.
I add an errhint() to one of these new errors, but I'm undecided about
that idea --- should we add errhint() to all three messages, or none?
We can't do this in back branches, of course (incl. 17 at this point),
because that might break existing applications, which means we need to
adjust behavior in some other way, probably similar to what Tender Wang
suggested, namely just don't crash on detach, or something like that.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Attachments:
[text/x-diff] v2-0001-WIP-don-t-let-constraint-indexes-attach-to-raw-in.patch (0B, ../../202406281127.piekjwgnulgf@alvherre.pgsql/2-v2-0001-WIP-don-t-let-constraint-indexes-attach-to-raw-in.patch)
download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-06-29 00:15 ` Michael Paquier <michael@paquier.xyz>
2024-06-29 04:37 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 1 reply; 24+ messages in thread
From: Michael Paquier @ 2024-06-29 00:15 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Tender Wang <tndrwang@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Fri, Jun 28, 2024 at 01:27:17PM +0200, Alvaro Herrera wrote:
> I guess you could also fix this by adding a PK constraint to the parent
> table, so that the situation is consistent in the other direction.
Yes, I've also considered this option when thinking about this thread,
but forcing a constraint creation up to the parent felt non-intuitive
to me as we force creation of catalog entries on the children based on
the state of the parent for basically everything else. So introducing
a new path where we would do the reverse is a recipe for more complex
code in tablecmds.c, which I'd rather avoid.
> Here's a proposed patch for master only. It turns all three situations
> being reported into ereport(ERROR); in one case I have an XXX comment,
> because we have an alternative when attaching a partition that already
> has a PK to a partitioned table that has a non-PK index: just create a
> separate index in the partition. But that would cause slowness, which
> is probably undesirable. I'm inclined to just remove the XXX comment,
> but if anyone has other thoughts, they are welcome.
An error sounds saner here in the long term.
Tests for all of the code paths involved, perhaps? ;)
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../../Zn9SDY0r9fLTqqDO@paquier.xyz/2-signature.asc)
download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 00:15 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
@ 2024-06-29 04:37 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-29 17:56 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 24+ messages in thread
From: Laurenz Albe @ 2024-06-29 04:37 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Tender Wang <tndrwang@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sat, 2024-06-29 at 09:15 +0900, Michael Paquier wrote:
> > Here's a proposed patch for master only. It turns all three situations
> > being reported into ereport(ERROR); in one case I have an XXX comment,
> > because we have an alternative when attaching a partition that already
> > has a PK to a partitioned table that has a non-PK index: just create a
> > separate index in the partition. But that would cause slowness, which
> > is probably undesirable. I'm inclined to just remove the XXX comment,
> > but if anyone has other thoughts, they are welcome.
>
> An error sounds saner here in the long term.
>
> Tests for all of the code paths involved, perhaps? ;)
My example that triggered this assert runs just fine on v16.
So while an error is clearly better than a crash, that would constitute
a regression. Is that really unavoidable? It would be very unfortunate
if the only way to detach a partition would be to drop some indexes first...
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 00:15 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-29 04:37 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
@ 2024-06-29 17:56 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 19:10 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 24+ messages in thread
From: Alvaro Herrera @ 2024-06-29 17:56 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Michael Paquier <michael@paquier.xyz>; Tender Wang <tndrwang@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 2024-Jun-29, Laurenz Albe wrote:
> My example that triggered this assert runs just fine on v16.
Well, in a build without assertions enabled then yes it doesn't crash.
But if you do have asserts enabled in 16, it does crash.
> So while an error is clearly better than a crash, that would constitute
> a regression. Is that really unavoidable? It would be very unfortunate
> if the only way to detach a partition would be to drop some indexes first...
The error would not occur on detach, but on attach, and it'd be intended
to prevent an inconsistent situation. I'm proposing that on older
branches we do what Tender proposed elsewhere, namely to cope with the
detach without crashing (and without leaving inconsistent catalog state,
such as bogus coninhcount values).
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Pero la cosa no es muy grave ..." (le petit Nicolas -- René Goscinny)
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 00:15 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-29 04:37 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-29 17:56 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-06-29 19:10 ` Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 0 replies; 24+ messages in thread
From: Laurenz Albe @ 2024-06-29 19:10 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; Tender Wang <tndrwang@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sat, 2024-06-29 at 19:56 +0200, Alvaro Herrera wrote:
> On 2024-Jun-29, Laurenz Albe wrote:
>
> > My example that triggered this assert runs just fine on v16.
>
> Well, in a build without assertions enabled then yes it doesn't crash.
> But if you do have asserts enabled in 16, it does crash.
>
> > So while an error is clearly better than a crash, that would constitute
> > a regression. Is that really unavoidable? It would be very unfortunate
> > if the only way to detach a partition would be to drop some indexes first...
>
> The error would not occur on detach, but on attach, and it'd be intended
> to prevent an inconsistent situation. I'm proposing that on older
> branches we do what Tender proposed elsewhere, namely to cope with the
> detach without crashing (and without leaving inconsistent catalog state,
> such as bogus coninhcount values).
I should have read more closely, sorry. That's great then; sorry for the noise.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-07-03 18:21 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-04 07:57 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-07-04 12:17 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
1 sibling, 2 replies; 24+ messages in thread
From: Alvaro Herrera @ 2024-07-03 18:21 UTC (permalink / raw)
To: Tender Wang <tndrwang@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Did anybody figure out a way to repair the problematic situation without
having to recreate the whole index hierarchy? If so, please let me
know. For full context, see below.
On 2024-Jun-28, Alvaro Herrera wrote:
> Here's a proposed patch for master only. It turns all three situations
> being reported into ereport(ERROR); in one case I have an XXX comment,
> because we have an alternative when attaching a partition that already
> has a PK to a partitioned table that has a non-PK index: just create a
> separate index in the partition. But that would cause slowness, which
> is probably undesirable. I'm inclined to just remove the XXX comment,
> but if anyone has other thoughts, they are welcome.
>
> I add an errhint() to one of these new errors, but I'm undecided about
> that idea --- should we add errhint() to all three messages, or none?
>
> We can't do this in back branches, of course (incl. 17 at this point),
> because that might break existing applications, which means we need to
> adjust behavior in some other way, probably similar to what Tender Wang
> suggested, namely just don't crash on detach, or something like that.
So here are three patches. 0001 adds a check at DETACH time so that if
a constraint has the form that we don't want to see, it copes without
crashing in the way Tender suggested. The code is different though,
mainly because we don't need his proposed has_superclass() function. It
also adds the test cases, and leaves one of the tables from it so that
pg_upgrade is tested.
0002 is the code that throws an error in any of the three problem cases;
roughly the same as the patch I posted as 0001 upthread. This is
incomplete in the sense that the regression tests would fail with it,
because I didn't modify the results. (I think we'd also remove the
DETACH line from those tests, because it'd be useless).
0003 adds the pg_upgrade check I mentioned: it scans the databases in
the source cluster for any constraints of the bogus form and fails the
upgrade if any exist. I tested this one very lightly (that is to say,
only with the database state left by the tests in 0001).
After staring at this third patch for a little bit, I'm not so sure
about rejecting the situation after all. The problem is that it is
quite tricky to get rid of the problem objects: you may have to accept a
length of time during which your partitioned table has no unique index
and the partitions have no primary keys, and you need to have a lot of
time and effort to recreate essentially those very same things, just to
get the PK created at the partitioned-table level instead of at the
partitions level. From a user's point of view this sounds rather
insane because of how inconvenient it is.
If we did have `ALTER TABLE partitioned ADD PRIMARY KEY USING INDEX`,
then it wouldn't be a problem, because you can repair the situation
cheaply and easily. So maybe a better plan is to retain the lenient
behavior for now (that is, push patch 0001 only), then add ALTER TABLE
ADD PRIMARY KEY USING INDEX (to 18 only of course), and only _then_ get
patches 0002 and 0003 pushed (to 18 only). If somebody does see a cheap
way to repair an existing database without having to recreate the
indexes, then my opinion would switch 180 degrees -- so please speak up
if you do.
BTW I didn't actually try the cases where the constraint is UNIQUE
rather than PRIMARY KEY (because that only occurred to me while I was
writing this email), but I suspect it should be more or less the same,
if not exactly identical.
Also, I should disclaim that I didn't try these scenarios on a server
compiled without assertions. I'll give them a run tomorrow, in case
there are further problems hidden behind the assertion failures.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-03 18:21 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-07-04 07:57 ` Tender Wang <tndrwang@gmail.com>
1 sibling, 0 replies; 24+ messages in thread
From: Tender Wang @ 2024-07-04 07:57 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年7月4日周四 02:21写道：
> Did anybody figure out a way to repair the problematic situation without
> having to recreate the whole index hierarchy? If so, please let me
> know. For full context, see below.
>
...Hmm, it is not trivial work. Strong consistency means that we
may sacrifice other things.
--
Tender Wang
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-03 18:21 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-07-04 12:17 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-05 02:24 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
1 sibling, 1 reply; 24+ messages in thread
From: Alvaro Herrera @ 2024-07-04 12:17 UTC (permalink / raw)
To: Tender Wang <tndrwang@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Doh, somehow I forgot the patches once again. Here they are. I intend
to push 0001 to all relevant branches soon, then park the rest until we
have ALTER TABLE ... ADD PRIMARY KEY USING INDEX.
On 2024-Jul-03, Alvaro Herrera wrote:
> So here are three patches. 0001 adds a check at DETACH time so that if
> a constraint has the form that we don't want to see, it copes without
> crashing in the way Tender suggested. The code is different though,
> mainly because we don't need his proposed has_superclass() function. It
> also adds the test cases, and leaves one of the tables from it so that
> pg_upgrade is tested.
>
> 0002 is the code that throws an error in any of the three problem cases;
> roughly the same as the patch I posted as 0001 upthread. This is
> incomplete in the sense that the regression tests would fail with it,
> because I didn't modify the results. (I think we'd also remove the
> DETACH line from those tests, because it'd be useless).
>
> 0003 adds the pg_upgrade check I mentioned: it scans the databases in
> the source cluster for any constraints of the bogus form and fails the
> upgrade if any exist. I tested this one very lightly (that is to say,
> only with the database state left by the tests in 0001).
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Attachments:
[text/x-diff] v3-0001-Cope-at-DETACH-time-for-12-16.patch (0B, ../../202407041217.tei7dtplpymg@alvherre.pgsql/2-v3-0001-Cope-at-DETACH-time-for-12-16.patch)
download
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-03 18:21 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-04 12:17 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-07-05 02:24 ` Tender Wang <tndrwang@gmail.com>
2024-07-12 10:57 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 24+ messages in thread
From: Tender Wang @ 2024-07-05 02:24 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年7月4日周四 20:17写道：
> Doh, somehow I forgot the patches once again. Here they are. I intend
> to push 0001 to all relevant branches soon, then park the rest until we
> have ALTER TABLE ... ADD PRIMARY KEY USING INDEX.
>
The 0001 looks good to me.
--
Tender Wang
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 09:19 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-03 18:21 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-04 12:17 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-05 02:24 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
@ 2024-07-12 10:57 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 0 replies; 24+ messages in thread
From: Alvaro Herrera @ 2024-07-12 10:57 UTC (permalink / raw)
To: Tender Wang <tndrwang@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 2024-Jul-05, Tender Wang wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年7月4日周四 20:17写道：
>
> > Doh, somehow I forgot the patches once again. Here they are. I intend
> > to push 0001 to all relevant branches soon, then park the rest until we
> > have ALTER TABLE ... ADD PRIMARY KEY USING INDEX.
>
> The 0001 looks good to me.
Thank you, I have pushed it with some comment rewording and changes to
the tests.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Michael Paquier <michael@paquier.xyz>
@ 2024-06-27 18:41 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2 siblings, 0 replies; 24+ messages in thread
From: Alvaro Herrera @ 2024-06-27 18:41 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tender Wang <tndrwang@gmail.com>; exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On 2024-Jun-12, Michael Paquier wrote:
> On Wed, Jun 12, 2024 at 01:49:32PM +0800, Tender Wang wrote:
> > I found another crash case as below:
> > CREATE TABLE t (a integer) PARTITION BY RANGE (a);
> > CREATE TABLE tp (a integer PRIMARY KEY);
> > CREATE UNIQUE INDEX t_a_idx ON t (a);
> > ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
> > ALTER TABLE t DETACH PARTITION tp;
> >
> > If index of parent is not created by adding constraint, it will trigger
> > assert fail.
>
> The 4th command is I think incorrect to attach "t_a_idx" to "tp"'s
> primary key index because "t" does not have an equivalent entry in
> pg_constraint. So that does not address the actual issue.
Actually, the partition index is attached to the parent index already at
CREATE UNIQUE INDEX, so it's the third line that's the problem (but what
you say is true too if the user says CREATE UNIQUE INDEX ON ONLY
parent).
I tend to agree that a good, consistent fix for this would be to forbid
a PK in a partition from becoming a child of a non-constraint index in
the parent ... A few ereport(ERROR)s sprinkled in various places might
be sufficient in the master branch, but perhaps we shouldn't disallow it
in stable branches because that might be problematic for existing apps;
and I suspect that we'd need to install protections in pg_upgrade to fix
databases from earlier branches being upgraded with the given hierarchy
(or just prevent the upgrade in --check and tell the users to fix it.)
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
@ 2024-06-19 04:29 ` Tender Wang <tndrwang@gmail.com>
2 siblings, 0 replies; 24+ messages in thread
From: Tender Wang @ 2024-06-19 04:29 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>
PG Bug reporting form <noreply@postgresql.org> 于2024年6月9日周日 20:58写道：
> The following bug has been logged on the website:
>
> Bug reference: 18500
> Logged by: Alexander Lakhin
> Email address: exclusion@gmail.com
> PostgreSQL version: 17beta1
> Operating system: Ubuntu 22.04
> Description:
>
> The following script:
> CREATE TABLE t (a integer) PARTITION BY RANGE (a);
> CREATE TABLE tp (a integer PRIMARY KEY);
> ALTER TABLE t ATTACH PARTITION tp FOR VALUES FROM (0) TO (1000);
>
> CREATE UNIQUE INDEX t_a_idx ON t (a);
> ALTER INDEX t_a_idx ATTACH PARTITION tp_pkey;
>
> \d+ t*
> ALTER TABLE t DETACH PARTITION tp;
>
> triggers an assertion failure as below:
> ...
> Partitioned index "public.t_a_idx"
> Column | Type | Key? | Definition | Storage | Stats target
> --------+---------+------+------------+---------+--------------
> a | integer | yes | a | plain |
> unique, btree, for table "public.t"
> Partitions: tp_pkey
> Access method: btree
> ...
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> connection to server was lost
>
> TRAP: failed Assert("constrForm->coninhcount == 0"), File:
> "pg_constraint.c", Line: 873, PID: 3272276
> ...
> #5 0x000055b26dc9b76f in ExceptionalCondition (
> conditionName=conditionName@entry=0x55b26dd2d254
> "constrForm->coninhcount == 0",
> fileName=fileName@entry=0x55b26dd2d230 "pg_constraint.c",
> lineNumber=lineNumber@entry=873) at assert.c:66
> #6 0x000055b26d8687d7 in ConstraintSetParentConstraint
> (childConstrId=16392, parentConstrId=parentConstrId@entry=0,
> childTableId=childTableId@entry=0) at pg_constraint.c:873
> #7 0x000055b26d9361c7 in DetachPartitionFinalize
> (rel=rel@entry=0x7f84a051d4b8, partRel=partRel@entry=0x7f84a0514428,
> concurrent=concurrent@entry=false,
> defaultPartOid=defaultPartOid@entry=0) at tablecmds.c:19306
> #8 0x000055b26d94449a in ATExecDetachPartition
> (wqueue=wqueue@entry=0x7fff8d338780, tab=tab@entry=0x55b26fcd6f90,
> rel=rel@entry=0x7f84a051d4b8, name=<optimized out>, concurrent=false)
> at
> tablecmds.c:19140
> #9 0x000055b26d944fe0 in ATExecCmd (wqueue=wqueue@entry=0x7fff8d338780,
> tab=tab@entry=0x55b26fcd6f90,
> cmd=<optimized out>, lockmode=lockmode@entry=8,
> cur_pass=cur_pass@entry=AT_PASS_MISC,
> context=context@entry=0x7fff8d338890) at tablecmds.c:5515
> ...
>
> Without asserts enabled, DETACH executed with no error.
>
> Reproduced on REL_11_STABLE .. master.
>
Hi Alvaro,
I tried to fix this issue on v1 patch. Since the related codes were
commited by you.
So do you have some advides about how to fix the reported issue.
Thanks.
--
Tender Wang
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
@ 2024-06-27 13:54 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-27 14:01 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
2 siblings, 1 reply; 24+ messages in thread
From: Laurenz Albe @ 2024-06-27 13:54 UTC (permalink / raw)
To: exclusion@gmail.com; pgsql-bugs@lists.postgresql.org
On Sun, 2024-06-09 at 06:00 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18500
> Logged by: Alexander Lakhin
> Email address: exclusion@gmail.com
> PostgreSQL version: 17beta1
> Operating system: Ubuntu 22.04
> Description:
FYI, I think that the same problem just happened to me with v17beta2:
test=> CREATE TABLE p (id integer) PARTITION BY RANGE (id);
CREATE TABLE
test=> CREATE TABLE p_1 PARTITION OF p FOR VALUES FROM (1) TO (2);
CREATE TABLE
test=> ALTER TABLE p_1 ADD PRIMARY KEY (id);
ALTER TABLE
test=> CREATE UNIQUE INDEX ON p (id);
CREATE INDEX
test=> ALTER TABLE p DETACH PARTITION p_1;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-27 13:54 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
@ 2024-06-27 14:01 ` Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
2024-06-27 14:55 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 24+ messages in thread
From: Daniel Westermann (DWE) @ 2024-06-27 14:01 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; exclusion@gmail.com <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
>On Sun, 2024-06-09 at 06:00 +0000, PG Bug reporting form wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 18500
>> Logged by: Alexander Lakhin
>> Email address: exclusion@gmail.com
>> PostgreSQL version: 17beta1
>> Operating system: Ubuntu 22.04
>> Description:
>FYI, I think that the same problem just happened to me with v17beta2:
>test=> CREATE TABLE p (id integer) PARTITION BY RANGE (id);
>CREATE TABLE
>test=> CREATE TABLE p_1 PARTITION OF p FOR VALUES FROM (1) TO (2);
>CREATE TABLE
>test=> ALTER TABLE p_1 ADD PRIMARY KEY (id);
>ALTER TABLE
>test=> CREATE UNIQUE INDEX ON p (id);
>CREATE INDEX
>test=> ALTER TABLE p DETACH PARTITION p_1;
>server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
Doesn't happen on FreeBSD:
postgres=# CREATE TABLE p (id integer) PARTITION BY RANGE (id);
CREATE TABLE
postgres=# CREATE TABLE p_1 PARTITION OF p FOR VALUES FROM (1) TO (2);
CREATE TABLE
postgres=# ALTER TABLE p_1 ADD PRIMARY KEY (id);
ALTER TABLE
postgres=# CREATE UNIQUE INDEX ON p (id);
CREATE INDEX
postgres=# ALTER TABLE p DETACH PARTITION p_1;
ALTER TABLE
postgres=# \! cat /etc/os-release
NAME=FreeBSD
VERSION="14.1-RELEASE-p1"
VERSION_ID="14.1"
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 14.1-RELEASE-p1"
CPE_NAME="cpe:/o:freebsd:freebsd:14.1"
HOME_URL="https://FreeBSD.org/";
BUG_REPORT_URL="https://bugs.FreeBSD.org/";
postgres=#
Regards
Daniel
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-27 13:54 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-27 14:01 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
@ 2024-06-27 14:55 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-28 00:18 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 24+ messages in thread
From: Alvaro Herrera @ 2024-06-27 14:55 UTC (permalink / raw)
To: Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; exclusion@gmail.com <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 2024-Jun-27, Daniel Westermann (DWE) wrote:
> Doesn't happen on FreeBSD:
Maybe this one uses Postgrs compiled with assertions disabled (would be
what I expect in a "production" build).
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"No deja de ser humillante para una persona de ingenio saber
que no hay tonto que no le pueda enseñar algo." (Jean B. Say)
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-27 13:54 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-27 14:01 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
2024-06-27 14:55 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-06-28 00:18 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-28 09:17 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 24+ messages in thread
From: Laurenz Albe @ 2024-06-28 00:18 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>; +Cc: exclusion@gmail.com <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Thu, 2024-06-27 at 16:55 +0200, Alvaro Herrera wrote:
> On 2024-Jun-27, Daniel Westermann (DWE) wrote:
>
> > Doesn't happen on FreeBSD:
>
> Maybe this one uses Postgrs compiled with assertions disabled (would be
> what I expect in a "production" build).
Ah, right. I used Devrim's RPM packages, and I see that they are built with
--enable-cassert.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-27 13:54 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-27 14:01 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
2024-06-27 14:55 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-28 00:18 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
@ 2024-06-28 09:17 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-28 10:59 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Devrim Gündüz <devrim@gunduz.org>
0 siblings, 1 reply; 24+ messages in thread
From: Alvaro Herrera @ 2024-06-28 09:17 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>; exclusion@gmail.com <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>; Devrim Gündüz <devrim@gunduz.org>
On 2024-Jun-28, Laurenz Albe wrote:
> On Thu, 2024-06-27 at 16:55 +0200, Alvaro Herrera wrote:
> > On 2024-Jun-27, Daniel Westermann (DWE) wrote:
> >
> > > Doesn't happen on FreeBSD:
> >
> > Maybe this one uses Postgrs compiled with assertions disabled (would be
> > what I expect in a "production" build).
>
> Ah, right. I used Devrim's RPM packages, and I see that they are built with
> --enable-cassert.
Oh yeah, I remember noticing that before and thinking that that was an
absolutely insane choice. Performance really suffers.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"I can't go to a restaurant and order food because I keep looking at the
fonts on the menu. Five minutes later I realize that it's also talking
about food" (Donald Knuth)
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-27 13:54 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-27 14:01 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
2024-06-27 14:55 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-28 00:18 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-28 09:17 ` Re: BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2024-06-28 10:59 ` Devrim Gündüz <devrim@gunduz.org>
0 siblings, 0 replies; 24+ messages in thread
From: Devrim Gündüz @ 2024-06-28 10:59 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>; exclusion@gmail.com <exclusion@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Hi,
On Fri, 2024-06-28 at 11:17 +0200, Alvaro Herrera wrote:
> > Ah, right. I used Devrim's RPM packages, and I see that they are
> > built with
> > --enable-cassert.
>
> Oh yeah, I remember noticing that before and thinking that that was an
> absolutely insane choice. Performance really suffers.
I think it is a very sane choice as we are talking about beta RPMs and
we need that for *testing*. I remove that flag in RC1.
Cheers,
--
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachments:
[application/pgp-signature] signature.asc (857B, ../../d56f106ccff6e95096de29b96e5cb11070309717.camel@gunduz.org/2-signature.asc)
download
^ permalink raw reply [nested|flat] 24+ messages in thread
end of thread, other threads:[~2024-07-12 10:57 UTC | newest]
Thread overview: 24+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-09 06:00 BUG #18500: Detaching a partition with an index manually attached to the parent's index triggers Assert PG Bug reporting form <noreply@postgresql.org>
2024-06-10 07:50 ` Michael Paquier <michael@paquier.xyz>
2024-06-12 05:49 ` Tender Wang <tndrwang@gmail.com>
2024-06-12 06:12 ` Michael Paquier <michael@paquier.xyz>
2024-06-12 06:44 ` Tender Wang <tndrwang@gmail.com>
2024-06-12 09:19 ` Tender Wang <tndrwang@gmail.com>
2024-06-28 11:27 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 00:15 ` Michael Paquier <michael@paquier.xyz>
2024-06-29 04:37 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-29 17:56 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-29 19:10 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-07-03 18:21 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-04 07:57 ` Tender Wang <tndrwang@gmail.com>
2024-07-04 12:17 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-07-05 02:24 ` Tender Wang <tndrwang@gmail.com>
2024-07-12 10:57 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-27 18:41 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-19 04:29 ` Tender Wang <tndrwang@gmail.com>
2024-06-27 13:54 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-27 14:01 ` Daniel Westermann (DWE) <daniel.westermann@dbi-services.com>
2024-06-27 14:55 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-28 00:18 ` Laurenz Albe <laurenz.albe@cybertec.at>
2024-06-28 09:17 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2024-06-28 10:59 ` Devrim Gündüz <devrim@gunduz.org>
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