Re: [HACKERS] postgres_fdw bug in 9.6 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] postgres_fdw bug in 9.6
Date
Msg-id CA+Tgmoa34SqEgWhriT38MN4ic7_Wn3Z_Y7kOBOsukNAkTxM77A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] postgres_fdw bug in 9.6  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: [HACKERS] postgres_fdw bug in 9.6
List pgsql-hackers
On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> I noticed that this test case added by the patch is not appropriate:
>
> +-- multi-way join involving multiple merge joins
> +EXPLAIN (VERBOSE, COSTS OFF)
> +SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1
> +    AND ft1.c1 = ft5.c1 FOR UPDATE;
> +SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1
> +    AND ft1.c1 = ft5.c1 FOR UPDATE;
>
> because it doesn't inject extra Sort nodes into EPQ recheck plans, so it
> works well without the fix.  I modified this to inject a Sort into the
> recheck plan of the very first foreign join.  Attached is a patch for that.

Mumble.  Tom provided me with that example and said it failed without
the patch.  I didn't check, I just believed him.  But I'm surprised if
he was wrong; Tom usually tries to avoid being wrong...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] make check with Apple's SIP enabled
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooling