On Sun, Dec 3, 2017 at 2:56 PM, Tom Lane <t...@sss.pgh.pa.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(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
