Subject: Re: The case when AsyncAppend exists also in the qual of Async
 ForeignScan
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
References: <fe5eaa19-1704-e4a4-76ee-3b9d37ade399@postgrespro.ru>
 <CAPmGK14goYe+6sCxwAMFoe0c7YYqT3WvANiqU_VAer-A8twSrg@mail.gmail.com>
 <CAPmGK15nLigSkr_kSiRmxn4vUv_EC4GAZ-veiUQ8UviDdF2Y3w@mail.gmail.com>
From: Andrey Lepikhov <a.lepikhov@postgrespro.ru>
Organization: Postgres Professional
Message-ID: <9b656dd9-62dc-bd61-ceae-5333cec2a966@postgrespro.ru>
Date: Thu, 8 Jul 2021 11:06:46 +0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: 
 <CAPmGK15nLigSkr_kSiRmxn4vUv_EC4GAZ-veiUQ8UviDdF2Y3w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/9b656dd9-62dc-bd61-ceae-5333cec2a966%40postgrespro.ru>
Precedence: bulk

On 8/7/21 10:49, Etsuro Fujita wrote:
> On Sat, Jul 3, 2021 at 8:35 AM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>> On Fri, Jul 2, 2021 at 10:24 PM Andrey Lepikhov
>> <a.lepikhov@postgrespro.ru> wrote:
>>> I found one bug. Look at the case:
>>>
>>> CREATE TABLE test (x int) PARTITION BY HASH (x);
>>> CREATE TABLE test_1 (x int);
>>> CREATE TABLE test_2 (x int);
>>> CREATE FOREIGN TABLE ftest_1 PARTITION OF test
>>>          FOR VALUES WITH (modulus 2, remainder 0)
>>>          SERVER loopback OPTIONS (table_name 'test_1');
>>> CREATE FOREIGN TABLE ftest_2 PARTITION OF test
>>>          FOR VALUES WITH (modulus 2, remainder 1)
>>>          SERVER loopback2 OPTIONS (table_name 'test_2');
>>> INSERT INTO test (SELECT * FROM generate_series(1,10));
>>> ANALYZE test,test_1,test_2,ftest_1,ftest_2;
>>>
>>> EXPLAIN (ANALYZE)
>>> SELECT * FROM test WHERE x NOT IN (
>>>          SELECT avg(x) FROM test WHERE x > 10
>>> );
>>> ERROR:  InstrEndLoop called on running node
>>>
>>> When I added ', COSTS OFF, SUMMARY OFF, TIMING OFF' this example fall
>>> down into the SEGFAULT.
>>>
>>> I prepared quick fix for this problem (see patch in attachment). Maybe
>>> it is'nt a best solution but it can speedup search of it.
>>
>> I’ll looking into this.  Thanks for the report and patch!
> 
> I tried to reproduce this in my environment using HEAD and PG14, but I
> couldn't.  Could you elaborate a bit more on how to reproduce this?
> 
> Best regards,
> Etsuro Fujita
> 
Initially I cought this bug during TPC-H benchmarking, query Q16, right 
after start of execution.
Key thing here is using a hashed subplan.

-- 
regards,
Andrey Lepikhov
Postgres Professional