| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Luis Carril <luis(dot)carril(at)swarm64(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, PG Bug reporting form <noreply(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Subject: | Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction |
| Date: | 2018-12-21 04:07:24 |
| Message-ID: | 20181221040724.GF1886@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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.
> Thanks for the updated patch!
And thanks for taking the time to review the patch.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Etsuro Fujita | 2018-12-21 05:10:10 | Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction |
| Previous Message | Etsuro Fujita | 2018-12-21 03:49:25 | Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction |