Message-ID: <5C19F7FF.9060904@lab.ntt.co.jp>
Date: Wed, 19 Dec 2018 16:49:19 +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: <15552-c64aa14c5c22f63c@postgresql.org>
 <8e82d10d-cc16-eed4-7634-3654f59d8053@lab.ntt.co.jp>
 <LEJPR01MB00109D0BECB8A961074A7CAFE7BC0@LEJPR01MB0010.DEUPRD01.PROD.OUTLOOK.DE>
 <30718b48-8020-329a-c6f0-74e1222e5283@lab.ntt.co.jp>
 <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>
In-Reply-To: <6daa6d4a-d4a9-bd2c-0b84-c4e31d2b9844@lab.ntt.co.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Michael Paquier <michael@paquier.xyz>,
        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/19 11:52), Amit Langote wrote:
> On 2018/12/19 11:38, Michael Paquier wrote:
>> I would rather not play with the semantics of heap_sync() on
>> the back branches as well as on a thread dealing with a bug about COPY
>> with foreign tables.  Such discussions deserve a larger audience on
>> -hackers.
>
> +1

OK, I agree with that too.

> Patch looks good, by the way.

Thanks for working on this, Michael!

>> it is a bit funny to see COPY FREEZE working for foreign tables
>> actually, but perhaps this has some use-cases for some FDWs, so I'd
>> rather not touch it.
>
> Hmm, note that we don't pass CopyState->freeze option to the FDW drivers
> today, though we may in the future when we add an *actual* COPY interface
> to FDWs.  Wouldn't it be a good idea to prevent specifying the FREEZE
> option for foreign tables as COPY targets until then?

Not sure.  In general, I think it would be a good thing that the FDW is 
able to see options specified in the COPY command, though.

> Of course, that's
> something for -hackers to consider.

Agreed.

BTW I noticed that this error occurs not only for foreign tables but for 
views with INSTEAD OF INSERT triggers.  Here is an example on HEAD:

postgres=# create table instead_of_insert_tbl(id serial, name text);
CREATE TABLE
postgres=# begin;
BEGIN
postgres=# create view instead_of_insert_tbl_view as select ''::text as str;
CREATE VIEW
postgres=# create function fun_instead_of_insert_tbl() returns trigger 
as $$ beg
in insert into instead_of_insert_tbl (name) values (new.str); return 
null; end;
$$ language plpgsql;
CREATE FUNCTION
postgres=# create trigger trig_instead_of_insert_tbl_view instead of 
insert on i
nstead_of_insert_tbl_view for each row execute procedure 
fun_instead_of_insert_t
bl();
CREATE TRIGGER
postgres=# copy instead_of_insert_tbl_view from stdin;
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself, or an EOF signal.
 >> test1
 >> \.
ERROR:  could not open file "base/13788/16426": そのようなファイルやディ 
レクトリはありません

("そのようなファイルやディレクトリはありません" means no such file or 
directory.)

To fix this I think we would also need the same treatment for the view case.

Best regards,
Etsuro Fujita