| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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-13 04:38:05 |
| Message-ID: | a7fc3233-6dd4-a6a4-1a0b-4885abfe1c3a@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018/09/13 12:37, Michael Paquier wrote:
> On Wed, Sep 12, 2018 at 12:14:00PM -0400, Tom Lane wrote:
>> 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
>
> Perhaps you are thinking about heap_create() which decides if a relkind
> can have storage created by setting create_storage. If you introduce a
> new macro, I would think that refactoring as well heap.c so as it makes
> use of it could make sense.
Ashutosh Bapat had proposed patches in this area last year [1], but it
seems the discussion didn't lead to any development.
Thanks,
Amit
[1] Macros bundling RELKIND_* conditions
https://www.postgresql.org/message-id/CAFjFpRcfzs%2Byst6YBCseD_orEcDNuAr9GUTraZ5GC%3DAvCYh55Q%40mail.gmail.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2018-09-13 04:58:05 | Re: executor relation handling |
| Previous Message | Amit Langote | 2018-09-13 04:36:22 | Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT |