Re: TRUNCATE on foreign table
От | Fujii Masao |
---|---|
Тема | Re: TRUNCATE on foreign table |
Дата | |
Msg-id | e03edf6f-d2d5-6067-bf46-d82e70c40cfb@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: TRUNCATE on foreign table (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: TRUNCATE on foreign table
|
Список | 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 по дате отправления: