Re: TRUNCATE on foreign tables

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kohei KaiGai <kaigai(at)heterodb(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TRUNCATE on foreign tables
Date: 2020-01-16 05:40:31
Message-ID: 20200116054031.GG3117@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 15, 2020 at 11:33:07PM +0900, Kohei KaiGai wrote:
> 2020年1月15日(水) 17:11 Michael Paquier <michael(at)paquier(dot)xyz>:
>> I have done a quick read through the patch. You have modified the
>> patch to pass down to the callback a list of relation OIDs to execute
>> one command for all, and there are tests for FKs so that coverage
>> looks fine.
>>
>> Regression tests are failing with this patch:
>> -- TRUNCATE doesn't work on foreign tables, either directly or
>> recursively
>> TRUNCATE ft2; -- ERROR
>> -ERROR: "ft2" is not a table
>> +ERROR: foreign-data wrapper "dummy" has no handler
>> You visibly just need to update the output because no handlers are
>> available for truncate in this case.
>>
> What error message is better in this case? It does not print "ft2" anywhere,
> so user may not notice that "ft2" is the source of the error.
> How about 'foreign table "ft2" does not support truncate' ?

It sounds to me that this message is kind of right. This FDW "dummy"
does not have any FDW handler at all, so it complains about it.
Having no support for TRUNCATE is something that may happen after
that. Actually, this error message from your patch used for a FDW
which has a handler but no TRUNCATE support could be reworked:
+ if (!fdwroutine->ExecForeignTruncate)
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("\"%s\" is not a supported foreign table",
+ relname)));
Something like "Foreign-data wrapper \"%s\" does not support
TRUNCATE"?

>> + <literal>frels_list</literal> is a list of foreign tables that are
>> + connected to a particular foreign server; thus, these foreign tables
>> + should have identical foreign server ID
>> The list is built by the backend code, so that has to be true.
>>
>> + foreach (lc, frels_list)
>> + {
>> + Relation frel = lfirst(lc);
>> + Oid frel_oid = RelationGetRelid(frel);
>> +
>> + if (server_id == GetForeignServerIdByRelId(frel_oid))
>> + {
>> + frels_list = foreach_delete_current(frels_list, lc);
>> + curr_frels = lappend(curr_frels, frel);
>> + }
>> + }
>> Wouldn't it be better to fill in a hash table for each server with a
>> list of relations?
>
> It's just a matter of preference. A temporary hash-table with server-id
> and list of foreign-tables is an idea. Let me try to revise.

Thanks. It would not matter much for relations without inheritance
children, but if truncating a partition tree with many foreign tables
using various FDWs that could matter performance-wise.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-01-16 05:50:01 Re: remove some STATUS_* symbols
Previous Message Peter Griggs 2020-01-16 05:32:34 Re: [QUESTION/PROPOSAL] loose quadtree in spgist