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
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 |