Re: BUG #18806: When enable_rartitionwise_join is set to ON, the database shuts down abnormally

Tender Wang <tndrwang(at)gmail(dot)com> 于2025年2月12日周三 19:48写道：

>
>
> Tender Wang <tndrwang(at)gmail(dot)com> 于2025年2月12日周三 17:48写道：
>
>>
>>
>> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 于2025年2月12日周三 15:38写道：
>>
>>> On Wed, 2025-02-12 at 07:01 +0000, PG Bug reporting form wrote:
>>> > PostgreSQL version: 17.2
>>> > Operating system: CentOS Linux release 7.9.2009 (Core)
>>> > Description:
>>> >
>>> > After upgrading PG17.2, testing found that when
>>> enable_rartitionwise_join is
>>> > set to ON, when executing a query, if the main query and subquery have
>>> the
>>> > same table, the query will report an error.
>>> >
>>> > The database log shows the following error:
>>> > LOG: server process (PID 24796) was terminated by signal 6: Aborted
>>> > DETAIL: Failed process was running: select * from test t join orders
>>> o on
>>> > t.order_id =o.order_id where t.order_id in (select order_id from
>>> orders);
>>> > LOG: terminating any other active server processes
>>>
>>> That is a crash that may well indicate a PostgreSQL bug.
>>>
>>> However, without a way to reproduce the behavior, we won't be able to fix
>>> the problem. Try to come up with a self-contained test case. It would
>>> also be interesting to know which PostgreSQL extensions are present.
>>>
>>>
>> I can reproduce this crash on HEAD.
>>
>> postgres=# create table test(order_id int, name varchar);
>> create table orders(order_id int, name char(10)) partition by hash
>> (order_id);
>> CREATE TABLE
>> CREATE TABLE
>> postgres=# set enable_partitionwise_join = on;
>> SET
>> postgres=# create table orders_p1 partition of orders for values with (
>> modulus 32, remainder 0);
>> CREATE TABLE
>> postgres=# explain select * from test t join orders o on
>> t.order_id =o.order_id where t.order_id in (select order_id from orders);
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset: Succeeded.
>>
>>
> I debug this crash, I found this crash was related with below commit:
> commit 5278d0a2e870c61f9374a7796b90e6f9f6a73638
> Author: Amit Langote <amitlan(at)postgresql(dot)org>
> Date: Mon Mar 25 12:02:40 2024 +0900
>
> Reduce memory used by partitionwise joins
>
>
> the joinlist in this query is 1,2,5
> 1 means table t
> 2 means table orders
> 5 also means table orders, which subquery is pulled up.
> When we create join rel for (2,5), then wen enter try_partitionwise_join().
> In this func, we call build_child_join_sjinfo() to build SpecialJoinInfo
> for child.
> In build_child_join_sjinfo(), we use memcpy(), I think we should use
> copyObject().
> Otherwise, the parent_sjinfo will be freed, for example, after
> call free_child_join_sjinfo(),
> the parent_sjinfo min_lefthand looks like as below:
>
> (gdb) p *parent_sjinfo->min_lefthand
> $7 = {type = 3951489872, nwords = 21994, words = 0x55eaeb8696b0}
>
> The above bitmap is invalid, so trigger the Assert(bms_is_valid_set(a));
>
> Attached patch is my fix. Any thoughts?
>

I forgot sjinfo had called makeNode(), in v1 patch, origin memory to
sjinfo will leak, so I do a little adjust in v2 patch.

--
Thanks,
Tender Wang