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

From Tender Wang
Subject Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
Date
Msg-id CAHewXNkDzN9=1z_XM=V1HAZWzxBRXs9-0gjg-hxiCU3z4JFoYA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
List pgsql-bugs


Alvaro Herrera <alvherre@alvh.no-ip.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

pgsql-bugs by date:

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