From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT |
Date: | 2018-09-12 16:14:00 |
Message-ID: | 7193.1536768840@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-09-12 16:21:57 | Re: Consistent segfault in complex query |
Previous Message | Andrew Gierth | 2018-09-12 16:13:13 | Re: Consistent segfault in complex query |