Message-ID: <5C1C75B2.9000008@lab.ntt.co.jp>
Date: Fri, 21 Dec 2018 14:10:10 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: BUG #15552: Unexpected error in COPY to a foreign table in a
 transaction
References: <5C18ECBB.2000507@lab.ntt.co.jp>
 <LEJPR01MB001074FD67CB65B539122E4DE7BD0@LEJPR01MB0010.DEUPRD01.PROD.OUTLOOK.DE>
 <3539e73a-313a-5406-27c7-850affb47921@lab.ntt.co.jp>
 <20181219023814.GA6577@paquier.xyz>
 <6daa6d4a-d4a9-bd2c-0b84-c4e31d2b9844@lab.ntt.co.jp>
 <5C19F7FF.9060904@lab.ntt.co.jp> <20181219083422.GA680@paquier.xyz>
 <5C1A0B6C.1040502@lab.ntt.co.jp> <20181220003140.GE27104@paquier.xyz>
 <5C1C62C5.8040409@lab.ntt.co.jp> <20181221040724.GF1886@paquier.xyz>
In-Reply-To: <20181221040724.GF1886@paquier.xyz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
To: Michael Paquier <michael@paquier.xyz>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>,
        Luis Carril <luis.carril@swarm64.com>,
        "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>,
        PG Bug reporting form <noreply@postgresql.org>,
        Michael Paquier <michael.paquier@gmail.com>
Precedence: bulk

(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