Re: TRUNCATE on foreign table
От | Michael Paquier |
---|---|
Тема | Re: TRUNCATE on foreign table |
Дата | |
Msg-id | YGFdxlYGCZ+Oe+Lz@paquier.xyz обсуждение исходный текст |
Ответ на | Re: TRUNCATE on foreign table (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: TRUNCATE on foreign table
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: