Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: 1026592243(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
Date: 2024-06-11 07:44:21
Message-ID: CAHewXNnFa7yf4=bvPzrqS8QuziywAHELje2OwKP+oRcNzs5oCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 于2024年6月10日周一 23:33写道:

> On 2024-May-22, Tender Wang wrote:
>
> > I have tested this patch locally and did not encounter any failures.
> > I will take time to look the patch in detail and consider the issues you
> > mentioned.
>
> Thanks for testing! I've spend some more time playing with this, and I
> confirmed my fears that it's possible to hit the case where one
> partition is added and another is removed, so the count of partitions is
> the same, yet their OIDs don't match (problem [2] in my previous email).
> This means we're forced to memcmp() the arrays even when nparts match.
> We can reuse the maps if the partition OID arrays are bitwise identical,
> otherwise we map the partitions one by one into subpart_map / subplan_map.

> I ended up splitting the code fix in two parts, one for
> RelationBuildPartitionDesc and the other for CreatePartitionPruneState,
> because the two areas being touch have independent bugs that seem more
> easily explained separately. However, I was unable to trigger the bug
> that 0001 fixes without involving the code in 0002. The commit messges
> should explain each bug and fix in enough detail, I hope.
>

I‘m ok with 0001 and 0002. No failures any more on my machine.

>
> I'm not happy about the comment changes in 0002: I think I'm losing some
> of the original comments that should perhaps be retained. I'll look
> into that, but I'll push 0001 soon.
>
> (Both these patches are needed from 14 onwards, where DETACH
> CONCURRENTLY was added.)
>
> --
> Álvaro Herrera Breisgau, Deutschland —
> https://www.EnterpriseDB.com/
> "In fact, the basic problem with Perl 5's subroutines is that they're not
> crufty enough, so the cruft leaks out into user-defined code instead, by
> the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
>

--
Tender Wang
OpenPie: https://en.openpie.com/

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2024-06-11 07:44:57 Re: error "can only drop stats once" brings down database
Previous Message Michael Paquier 2024-06-10 23:10:46 Re: BUG #18483: Segmentation fault in tests modules