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

Поиск
Список
Период
Сортировка
От Tender Wang
Тема Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
Дата
Msg-id CAHewXNkDzN9=1z_XM=V1HAZWzxBRXs9-0gjg-hxiCU3z4JFoYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Potential data loss due to race condition during logical replication slot creation
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #18520: Different results when analyze a relation with UDT.