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
