Horton

Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
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>
Date: 2018-12-21T07:51:23Z
Lists: pgsql-bugs 
On Fri, Dec 21, 2018 at 02:10:10PM +0900, Etsuro Fujita wrote:
> 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.

The conflicts would be a bit annoying yes, still those are minimal so
I would still use the macro on HEAD.  Let's see if others have an
opinion.  We will have a divergence between v10 and v11 anyway as v11
has added support for COPY with foreign tables, and v10 has added
support for COPY with views.
--
Michael

Commits

  1. Disable WAL-skipping optimization for COPY on views

  2. Disable WAL-skipping optimization for COPY on views and foreign tables