Re: TRUNCATE on foreign table
От | Fujii Masao |
---|---|
Тема | Re: TRUNCATE on foreign table |
Дата | |
Msg-id | ac31f2db-e607-a2bb-2e8a-dd01a2e4f881@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: TRUNCATE on foreign table (Kazutaka Onishi <onishi@heterodb.com>) |
Ответы |
Re: TRUNCATE on foreign table
|
Список | pgsql-hackers |
On 2021/03/28 2:37, Kazutaka Onishi wrote: > Fujii-san, > > Thank you for your review! > Now I prepare v5 patch and I'll answer to your each comment. please > check this again. Thanks a lot! > 5. For example, we can easily do that by truncate foreign tables > before local ones. Thought? > > Umm... yeah, I feel it's better procedure, but not so required because > TRUNCATE is NOT called frequently. > Certainly, we already have postgresIsForeignUpdatable() to check > whether the foreign table is updatable or not. > Following this way, we have to add postgresIsForeignTruncatable() to check. > However, Unlike UPDATE, TRUNCATE is NOT called frequently. Current > procedure is inefficient but works correctly. > Thus, I feel postgresIsForeignTruncatable() is not needed. I'm concerned about the case where permission errors at the remote servers rather than that truncatable option is disabled. The comments of ExecuteTruncate() explains its design as follows. But the patch seems to break this because it truncates the local tables before checking the permission on foreign tables (i.e., the local tables in remote servers)... No? We first open and grab exclusive lock on all relations involved, checking permissions and otherwise verifying that the relation is OK for truncation Finally all the relations are truncated and reindexed. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: