Re: [HACKERS] postgres_fdw bug in 9.6

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: [HACKERS] postgres_fdw bug in 9.6
Дата
Msg-id 5A2E32DB.6090403@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] postgres_fdw bug in 9.6  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] postgres_fdw bug in 9.6  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
(2017/12/09 5:53), Robert Haas wrote:
> On Sun, Dec 3, 2017 at 2:56 PM, Tom Lane<tgl@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().

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

Best regards,
Etsuro Fujita

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: SIGPIPE in TAP tests
Следующее
От: Noah Misch
Дата:
Сообщение: Re: SIGPIPE in TAP tests