Re: TRUNCATE on foreign table

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

In response to

Responses

Browse pgsql-hackers by date

  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