|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: postgres_fdw bug in 9.6|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> [ epqpath-for-foreignjoin-11.patch ]
I started looking at this. I've not yet wrapped my head around what
CreateLocalJoinPath() is doing, but I noted that Robert's concerns
about ABI breakage in the back branches would not be very difficult
to satisfy. What we'd need to do is
(1) In the back-branch patch, add the new fields of JoinPathExtraData
at the end, rather than in their more natural locations. This should
avoid any ABI break for uses of that struct, since there's no reason
why an FDW would be creating its own variables of that type rather
than just using what the core code passes it.
(2) In the back branches, just leave GetExistingLocalJoinPath in place
rather than deleting it. Existing FDWs would still be subject to the
bug until they were updated, but given how hard it is to trigger, that
doesn't seem like a huge problem.
A variant of (2) is to install a hack fix in GetExistingLocalJoinPath
rather than leaving it unchanged. I'm not very excited about that though;
it doesn't seem unlikely that we might introduce new bugs that way, and
it would certainly be a distraction from getting the real fix finished.
We'd definitely need to do things that way in 9.6. I'm not quite sure
whether it's too late to adopt the clean solution in v10.
regards, tom lane
|Next Message||Robert Haas||2017-08-29 21:44:55||Re: Make pg_regress print a connstring with sockdir|
|Previous Message||Robert Haas||2017-08-29 21:13:25||Re: Speed up Clog Access by increasing CLOG buffers|