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

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: 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>
Subject: Re: BUG #15552: Unexpected error in COPY to a foreign table in a transaction
Date: 2018-12-18 03:24:54
Message-ID: 30718b48-8020-329a-c6f0-74e1222e5283@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On 2018/12/17 22:12, Luis Carril wrote:
> Hi,
>
>> heap_sync should only be called for relations that actually have files to
>> sync, which isn't true for foreign tables. So, a simple relkind check
>> before calling heap_sync() in CopyFrom would suffice I think. Although,
>> we might also need such a check higher up in CopyFrom where some
>> optimizations that are specific to "heap" relations are enabled. For
>> example, this piece of code:
>
> thanks for the input, so it seems that is enough with adding the check as you suggested:
>
> if (cstate->rel->rd_rel->relkind != RELKIND_PARTITIONED_TABLE &&
> cstate->rel->rd_rel->relkind != RELKIND_FOREIGN_TABLE &&
> (cstate->rel->rd_createSubid != InvalidSubTransactionId ||
> cstate->rel->rd_newRelfilenodeSubid != InvalidSubTransactionId))
> {
> hi_options |= HEAP_INSERT_SKIP_FSM;
> if (!XLogIsNeeded())
> hi_options |= HEAP_INSERT_SKIP_WAL;
> }

I think that would do the trick.

> Should a regression test be added (at postgres_fdw.sql)? If yes, how should be implemented, as max_wal_senders and wal_level need to be changed (to 0 and minimal) to trigger the bug, which is only possible on server start.

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:

+ -- Test that COPY FROM works correctly when the foreign table is created in
+ -- the same transaction
+ create table test_copy_same_txn_loc (f1 int, f2 text);
+ alter table test_copy_same_txn_loc set (autovacuum_enabled = 'false');
+ begin;
+ create foreign table test_copy_same_txn_rem (f1 int, f2 text) server
loopback options(table_name 'test_copy_same_txn_loc');
+ copy test_copy_same_txn_rem from stdin;
+ ERROR: could not open file "base/19888/20234": No such file or directory
+ commit;
+ drop table test_copy_same_txn_loc;
+ drop foreign table test_copy_same_txn_rem;
+ ERROR: foreign table "test_copy_same_txn_rem" does not exist
-- ===================================================================
-- test IMPORT FOREIGN SCHEMA
-- ===================================================================

From the above output, your patch will make "ERROR: could not open file
xxx" go away.

Thanks,
Amit

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2018-12-18 04:05:00 Re: BUG #15548: Unaccent does not remove combining diacritical characters
Previous Message PG Bug reporting form 2018-12-18 01:24:14 BUG #15557: pgadmin4 backup error