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-24 08:43:39
Message-ID: CAHewXNkDzN9=1z_XM=V1HAZWzxBRXs9-0gjg-hxiCU3z4JFoYA@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月21日周五 20:39写道:

> I noticed further problems with this patch, and it turned out to have
> other bugs that would manifest under very high concurrency of detach and
> attach (I think the problem was a detach followed by an immediate attach
> of the same partition, or perhaps it was an attach of a neighboring
> partition), so I spent more time ironing those out and ended up with the
> following, which I'm rather embarrased not to have had as the previous
> version because it looks simpler and more obvious.
>
> Unless further surprises arise soon, I'll push this soonish.
>

If we abstract the problem that this patch attempts to solve,it would try
to find same elements on two arrays.
The lengths of these two arrays are not guaranteed to be equal. In this
issue, even though the lengths of two arrays
is same, we can't assume the each element on two arrays is same.

The algorithm used in patch is correct if I understand correctly.

--
Tender Wang

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-06-24 10:10:01 BUG #18520: Different results when analyze a relation with UDT.
Previous Message Masahiko Sawada 2024-06-24 05:01:49 Re: Potential data loss due to race condition during logical replication slot creation