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

From Amit Langote
Subject Re: Getting ERROR: could not open file "base/13164/t3_16388" withpartition table with ON COMMIT
Date
Msg-id 0fc17e89-80cf-3c65-56ee-9765c2300b43@lab.ntt.co.jp
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>)
List pgsql-hackers
On 2018/11/05 9:19, Michael Paquier wrote:
> On Fri, Nov 02, 2018 at 04:39:07PM +0900, Amit Langote wrote:
>> Agreed that they're two independent issues, although it wouldn't be such a
>> bad idea to fix them in one go, as they're both issues related to the
>> handling of ON COMMIT actions on tables in inheritance trees.
> 
> I have pushed 0001 which fixes the bug reported on this thread down to
> v10, after tweaking a bit the patch after more review.  I was testing
> heap_truncate_one_rel() a bit more deeply and it actually happens that
> it can work with matviews.  Re-reading the thread and sleeping on it,
> Tom was been actually suggesting to move the check one level down to
> heap_truncate_one_rel(), which actually makes more sense.  So I have
> changed the patch so as a check on RELKIND_PARTITIONED_TABLE is done
> instead of RELKIND_RELATION which is what has been proposed until now.

Okay, it's good that heap_truncate_one_rel() continues to work for all
relation types that can have storage.  Thanks for making the changes
yourself and committing.

> Regarding the second patch, could you start a second thread?  The scope
> is not only related to partitioned tables but also to inheritance trees
> so this goes way back in time, and I think that we could attract a
> better audience about the problem.  I don't mind starting a thread
> myself, not without your authorization as you wrote a patch to deal with
> the problem.  My apologies, I have not looked at what you are proposing
> yet.

Okay, no problem.  I will post that patch in a new thread detailing what
the problem is and how the proposed patch fixes it.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Haozhou Wang
Date:
Subject: Re: Vacuum Full does not release the disk size space after deletefrom table
Next
From: Amit Langote
Date:
Subject: Re: Hooks to Modify Execution Flow and Query Planner