Re: TRUNCATE on foreign table - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: TRUNCATE on foreign table
Date
Msg-id e03edf6f-d2d5-6067-bf46-d82e70c40cfb@oss.nttdata.com
Whole thread Raw
In response to Re: TRUNCATE on foreign table  (Michael Paquier <michael@paquier.xyz>)
Responses Re: TRUNCATE on foreign table  (Kohei KaiGai <kaigai@heterodb.com>)
List pgsql-hackers

On 2021/03/29 13:55, Michael Paquier wrote:
> On Mon, Mar 29, 2021 at 10:53:14AM +0900, Fujii Masao wrote:
>> I understand the motivation of this. But the other DMLs like UPDATE also
>> do the same thing for foreign tables? That is, when those DML commands
>> are executed on foreign tables, their changes are WAL-logged in a publisher side,
>> e.g., for logical replication? If not, it seems strange to allow only TRUNCATE
>> on foreign tables to be WAL-logged in a publisher side...
> 
> Executing DMLs on foreign tables does not generate any WAL AFAIK with
> the backend core code, even with wal_level = logical, as the DML is
> executed within the FDW callback (see just ExecUpdate() or
> ExecInsert() in nodeModifyTable.c), and foreign tables don't have an
> AM set as they have no physical storage.  A FDW may decide to generate
> some WAL records by itself though when doing the opeation, using the
> generic WAL interface but that's rather limited.
> 
> Generating WAL for the truncation of foreign tables sounds also like a
> strange concept to me.  I think that you should just make the patch
> work so as the truncation is passed down to the FDW that decides what
> it needs to do with it, and do nothing more than that.

Agreed.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: "Joel Jacobson"
Date:
Subject: Re: Idea: Avoid JOINs by using path expressions to follow FKs