Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction - Mailing list pgsql-bugs

From Etsuro Fujita
Subject Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction
Date
Msg-id 5C1C75B2.9000008@lab.ntt.co.jp
Whole thread Raw
In response to Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction
List pgsql-bugs
(2018/12/21 13:07), Michael Paquier wrote:
> On Fri, Dec 21, 2018 at 12:49:25PM +0900, Etsuro Fujita wrote:
>> (2018/12/20 9:31), Michael Paquier wrote:
>>> Attached is the patch with two new test cases blowing with wal_level =
>>> minimal.  On HEAD, I suggest that we use RELKIND_CAN_HAVE_STORAGE to not
>>> fall again in this trap in the future.  For back-branches, let's just
>>> add the appropriate relkind checks as suggested upthread.
>>
>> To make maintenance easy, I think it might be better to add the appropriate
>> relkind checks on HEAD as well.  Other than that, the patch looks good to
>> me.
>
> Well, using RELKIND_CAN_HAVE_STORAGE is exactly to ease future
> maintenance so as we don't fall again into the same trap if a new
> relkind which has no physical storage gets introduced if it supports
> COPY FROM.  So I would keep really it on HEAD.

My point here is that if doing so, we would have 3 versions in PG10, 
PG11, and HEAD, which would make back-patching complicated.  So my taste 
would be to fix this on HEAD the same way as PG11, but I'm not against 
using RELKIND_CAN_HAVE_STORAGE on HEAD.

Best regards,
Etsuro Fujita



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction
Next
From: Michael Paquier
Date:
Subject: Re: BUG #15552: Unexpected error in COPY to a foreign table in atransaction