Re: [HACKERS] postgres_fdw bug in 9.6

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] postgres_fdw bug in 9.6
Date: 2017-12-11 07:25:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

(2017/12/09 5:53), Robert Haas wrote:
> On Sun, Dec 3, 2017 at 2:56 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Not sure where that leaves us for the patch at hand. It feels to me
>> like it's a temporary band-aid for code that we want to get rid of
>> in the not-too-long run. As such, it'd be okay if it were smaller,
>> but it seems bigger and more invasive than I could wish for a band-aid.
> Well, the bug report is a year old today, so we should try to do
> something. The patch needs a rebase, but reading through it, I'm not
> convinced that it's particularly risky. I mean, it's going to break
> FDWs that are calling GetExistingLocalJoinPath(), but there are
> probably very few third-party FDWs that do that. Any that do are
> precisely the ones that need this fix, so I think there's a good
> chance they'll forgive of us for requiring them to make a code change.
> I think we can contain the risk of anything else getting broken to an
> acceptable level because there's not really very much other code
> changing. The changes to joinpath.c need to be carefully audited to
> make sure that they are not changing the semantics, but that seems
> like it shouldn't take more than an hour of code-reading to check.
> The new fields in JoinPathExtraData can be moved to the end of the
> struct to minimize ABI breakage. I don't see what else there is that
> could break apart from the EPQ rechecks themselves, and if that
> weren't broken already, this patch wouldn't exist.
> Now, if you're still super-concerned about this breaking something, we
> could commit it only to master, where it will have 9 months to bake
> before it gets released. I think that's overly conservative, but I
> think it's still better than waiting for the rewrite you'd like to see
> happen. We don't know when or if anyone is going to undertake that,
> and if we wait, we may easing release a v11 that's got the same defect
> as v9.6 and now v10. And I don't see that we lose much by committing
> this now even if that rewrite does happen in time for v11. Ripping
> out CreateLocalJoinPath() won't be any harder than ripping out
> GetExistingLocalJoinPath().

Agreed. Attached is an rebased version which moved the new fields in
JoinPathExtraData to the end of that struct.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
epqpath-for-foreignjoin-12.patch text/x-diff 47.8 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2017-12-11 07:32:43 Re: SIGPIPE in TAP tests
Previous Message Michael Paquier 2017-12-11 07:19:52 Re: SIGPIPE in TAP tests