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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT
Дата
Msg-id 7193.1536768840@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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>)
Ответы 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
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> The infamous missing-relkind-check in heap_truncate() seems to be behind
> this.  Perhaps, a patch like the attached will do?

That seems excessively restrictive.  Anything that has storage (e.g.
matviews) ought to be truncatable, no?

I thought we had a macro or utility function somewhere that knew which
relkinds have storage, though I can't find it right now.  I'd be
inclined to instantiate that if it doesn't exist, and then the code
here ought to read something like

    if (RelkindHasStorage(rel->rd_rel->relkind))
        heap_truncate_one_rel(rel);

Also, possibly the test ought to be inside heap_truncate_one_rel
rather than its callers?

            regards, tom lane


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

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: Consistent segfault in complex query
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Consistent segfault in complex query