Обсуждение: Re: Bug in detaching a partition with a foreign key.

On Sat, Jan 18, 2025 at 2:14 AM Sami Imseih <samimseih@gmail.com> wrote:
>
> This is a bug indeed. I tried your patch, but it ends up in a seg fault.
>
> [...]
> If the relation on the parent and child constraint match, that
> tells us we don't have inheritance.
> So, I am thinking we should add another condition for checking
> if a foreign key is inherited by checking if the parent constraint
> relation is different from the child constraint relation.
>
> I am attaching an unpolished patch ( we need test coverage as well ) that
> implements  the above. All tests pass with this patch.

Thanks for confirming the bug. TBH, I haven't had a chance to look into the
issue in detail yet, but my understanding of the detach operation is that it
should cut the link between the parent constraint and the constraint on
the partition being detached. The trial patch I posted was meant to prevent
cutting the link between the partition's constraint and the constraint that
inherits it.  Your patch seems to achieve the same, AFAIUC, but I'm not sure I
like the way it's doing, nor the trial patch I posted. A crash is certainly
possible with that patch, but it would be helpful if you could provide more
context -- such as crash detail and/or a test case.

Regards,
Amul

> should cut the link between the parent constraint and the constraint on
> the partition being detached.
correct by setting the conparentid to 0 in pg_constraint and to delete
the pg_depend record for partition dependency. But in the repro case,
we don't have a dependency as the table the foreign key is on is a
partition.

> The trial patch I posted was meant to prevent
> cutting the link between the partition's constraint and the constraint that
> inherits it.  Your patch seems to achieve the same, AFAIUC,

Yes, exactly.

> but it would be helpful if you could provide more
> context -- such as crash detail and/or a test case.

Below is the repro I used. Similar as you original repro,
but without subpartition on foo_p0. This also results in the segfault
with your attached patch.

""
CREATE TABLE bar(id int PRIMARY KEY) PARTITION BY RANGE(id);
CREATE TABLE bar_p0 PARTITION OF bar FOR VALUES FROM (0) TO (100);
CREATE TABLE foo(id int) PARTITION BY RANGE(id);
CREATE TABLE foo_p0 PARTITION OF foo FOR VALUES FROM (0) TO (100);
ALTER TABLE foo_p0 ADD CONSTRAINT child_fk_con FOREIGN KEY (id) REFERENCES bar;
ALTER TABLE foo DETACH PARTITION foo_p0;
"""

Here is the core dump
"""
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `postgres: postgres postgres [local] ALTER T'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  GetMemoryChunkMethodID (pointer=0x0) at mcxt.c:205
205        header = *((const uint64 *) ((const char *) pointer -
sizeof(uint64)));

Thread 1 (Thread 0xffffb6e34f00 (LWP 17508)):
#0  GetMemoryChunkMethodID (pointer=0x0) at mcxt.c:205
        header = 12273896
#1  0x0000000000c05edc in repalloc (pointer=0x0, size=128) at mcxt.c:1566
        ret = 0x10b5b98380
#2  0x00000000007fbf24 in enlarge_list (list=0x18cd1490, min_size=1)
at list.c:209
        new_max_len = 16
#3  0x00000000007fc22c in new_tail_cell (list=0x18cd1490) at list.c:327
No locals.
#4  0x00000000007fc334 in lappend_oid (list=0x18cd1490, datum=16404)
at list.c:382
No locals.
"""

I was able to get your patch working by changing the way the fksid
is built with the below:

/* Collect all the constraint ids */
foreach(cell, fks)
{
       ForeignKeyCacheInfo *fk = lfirst(cell);
       fksids = lappend_oid(fksids, fk->conoid);
}


Regards,

Sami

On 2025-Jan-20, Sami Imseih wrote:

> Below is the repro I used. Similar as you original repro,
> but without subpartition on foo_p0. This also results in the segfault
> with your attached patch.

I think the issue in Amul's patch is just that the list was not
initialized to NIL.

Other than the lack of comments, which I'm in the process of writing,
the initial patch Amul submitted seems largely correct to me, in my
understanding of the situation.  I'll throw in a few tests, hoping that
it'll prove correct, and if so then I'll get it pushed soon.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"El hombre nunca sabe de lo que es capaz hasta que lo intenta" (C. Dickens)

The patch that Amul and I wrote both achieve the same result.
The approach that Amul took builds a list of constraint OIDs,
which could grow with the number of partitions and foreign keys
on those partitions. Maybe not a big deal?

In my suggestion [1], I just do one extra pg_constraint lookup
to determine If the relation on the parent and child constraint match,
and in that case we can skip the rest of the work to cut the
link as it's not needed.

Regards,

Sami

[1] https://www.postgresql.org/message-id/CAA5RZ0vk4SJ9PiD2RyG-CKOYvOFewz6QweKcp2_EegBKns%3DdOA%40mail.gmail.com

> > The patch that Amul and I wrote both achieve the same result.
> > The approach that Amul took builds a list of constraint OIDs,
> > which could grow with the number of partitions and foreign keys
> > on those partitions. Maybe not a big deal?

> Nope, not a big deal.  It would be a big deal if we were talking about
> 268 million partitions (>1GB palloc size), but that's impractical for
> other reasons.

that's fair.

Patch looks good to me, but I am not sure about this part of the comment:

"Only the topmost one is to be considered here; the child constraints
must be left alone,"

In this case, none of the pg_constraint entries are actually considered. right?

Regards,

Sami

On 2025-Jan-20, Sami Imseih wrote:

> Patch looks good to me, but I am not sure about this part of the comment:
> 
> "Only the topmost one is to be considered here; the child constraints
> must be left alone,"
> 
> In this case, none of the pg_constraint entries are actually considered. right?

Right.  The parent one because it has conparentid = 0, the others
because their parent constraint is in the list.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

On 2025-Jan-20, Sami Imseih wrote:

> Patch looks good to me,

Thanks, pushed.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

On Tue, Jan 21, 2025 at 7:25 PM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2025-Jan-20, Sami Imseih wrote:
>
> > Patch looks good to me,
>
> Thanks, pushed.
>
A big thanks to Álvaro and Sami for getting it fixed!

Regards,
Amul