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

On 2018/12/18 14:04, Michael Paquier wrote:
> On Tue, Dec 18, 2018 at 12:24:54PM +0900, Amit Langote wrote:
>> I noticed that too.  As you say, it is not possible to exercise a test we
>> might add for this with `make check`, because it runs with a fixed value
>> of wal_level (= replica).  But it is possible with `make installcheck` on
>> a cluster that's running with wal_level = minimal.  Maybe, something like
>> this:
>>
>> [...]
>>
>> From the above output, your patch will make "ERROR: could not open file
>> xxx" go away.
> 
> Last time we discussed about adding a test case in this area, we came up
> with a TAP test, so this could apply here as well:
> https://www.postgresql.org/message-id/f20181114.124736.206988673.horiguchi.kyotaro@lab.ntt.co.jp
> 
> What scares me a lot about complicating this code is that we are not
> seeing the end of it with this so-said optimization in removing the
> relfilenode like that...  There are other fancy cases where the failure
> can happen (please see patch 0001).

The link you shared is broken, so I couldn't read that email to understand
the relation of relfilenode removal optimization to the bug here or how a
TAP test was deployed for it.

To clarify, the bug in this case is that the optimization to skip writing
WAL if a "heap" relation being copied into is created in same
sub-transaction is mistakenly applied to foreign tables.

Thanks,
Amit