Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT
Дата
Msg-id 20181102015152.GU1727@paquier.xyz
обсуждение исходный текст
Ответ на Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: partitioned indexes and tablespaces
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: CF app feature request