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

From Michael Paquier
Subject Re: TRUNCATE on foreign table
Date
Msg-id YGFdxlYGCZ+Oe+Lz@paquier.xyz
Whole thread Raw
In response to Re: TRUNCATE on foreign table  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: TRUNCATE on foreign table  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: libpq debug log
Next
From: Michael Paquier
Date:
Subject: Re: invalid data in file backup_label problem on windows