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 |
Message-ID: | 5A2E32DB.6090403@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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 |
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 |