Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT
Date
Msg-id 20181102015152.GU1727@paquier.xyz
Whole thread Raw
In response to Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT
List pgsql-hackers
On Thu, Nov 01, 2018 at 01:04:43PM +0900, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 12:39:16PM +0900, Amit Langote wrote:
>> Rajkumar pointed out off-list that the patch still remains to be applied.
>> Considering that there is a planned point release on Nov 8, maybe we
>> should do something about this?
>
> Yes doing something about that very soon would be a good idea.  Tom,
> are you planning to look at it or should I jump in?

And so I am looking at v3 now...

Adding a test case in temp.sql would be nice.

Would it make sense to support TRUNCATE on a materialized as well in the
future?  It seems to me that it is dangerous to assume that only
relations make use of heap_truncate_one_rel() anyway as modules or
external code could perfectly call it.  And the thing is documented
to work on a relation, including materialized views, not just an
ordinary table which is what RELKIND_RELATION only mentions.  On the
contrary we know that heap_truncate() works only on temporary
relations.  It is documented to do so and does so.

So it seems to me that Tom correctly mentioned to add the check in
heap_truncate, not heap_truncate_one_rel(), so v3 looks incorrect to
me.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: partitioned indexes and tablespaces
Next
From: Andrew Dunstan
Date:
Subject: Re: CF app feature request