From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Kohei KaiGai <kaigai(at)heterodb(dot)com> |
Cc: | Kazutaka Onishi <onishi(at)heterodb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Subject: | Re: TRUNCATE on foreign table |
Date: | 2021-04-02 02:43:58 |
Message-ID: | 1ded9ac5-c5a0-15ed-71da-ba3e0c21dacf@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021/04/02 9:37, Kohei KaiGai wrote:
> It is fair enough for me to reverse the order of actual truncation.
>
> How about the updated comments below?
>
> This is a multi-relation truncate. We first open and grab exclusive
> lock on all relations involved, checking permissions (local database
> ACLs even if relations are foreign-tables) and otherwise verifying
> that the relation is OK for truncation. In CASCADE mode, ...(snip)...
> Finally all the relations are truncated and reindexed. If any foreign-
> tables are involved, its callback shall be invoked prior to the truncation
> of regular tables.
LGTM.
>> BTW, the latest patch doesn't seem to be applied cleanly to the master
>> because of commit 27e1f14563. Could you rebase it?
>>
> Onishi-san, go ahead. :-)
+1
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-04-02 02:44:25 | Re: shared-memory based stats collector |
Previous Message | 'alvherre@alvh.no-ip.org' | 2021-04-02 02:30:10 | Re: libpq debug log |