Re: Some memory not freed at the exit of RelationBuildPartitionDesc() - Mailing list pgsql-hackers

From amul sul
Subject Re: Some memory not freed at the exit of RelationBuildPartitionDesc()
Date
Msg-id CAAJ_b97QPT+b7jrFe80-PdvGLkeyfvCpkO6RxvvJtYTpwzRn9g@mail.gmail.com
Whole thread Raw
In response to Re: Some memory not freed at the exit of RelationBuildPartitionDesc()  (David Fetter <david@fetter.org>)
Responses Re: Some memory not freed at the exit of RelationBuildPartitionDesc()
List pgsql-hackers


On Sat, Aug 10, 2019 at 12:16 AM David Fetter <david@fetter.org> wrote:
On Thu, Aug 08, 2019 at 05:42:21PM +0900, Amit Langote wrote:
> On Thu, Aug 8, 2019 at 5:33 PM amul sul <sulamul@gmail.com> wrote:
> > On Thu, Aug 8, 2019 at 1:27 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> >> Thanks for the patch.  This was discussed recently in the "hyrax vs.
> >> RelationBuildPartitionDesc()" thread [1] and I think Alvaro proposed
> >> an approach that's similar to yours.  Not sure why it wasn't pursued
> >> though.  Maybe the reason is buried somewhere in that discussion.
> >
> > Oh, quite similar, thanks Amit for pointing that out.
> >
> > Look like "hyrax vs.RelationBuildPartitionDesc()" is in discussion for the master
> > branch only, not sure though, but we need the similar fix for the back branches as well.
>
> Well, this is not a bug as such, so it's very unlikely that a fix like
> this will be back-patched.  Also, if this becomes an issue only for
> more than over 1000 partitions, then it's not very relevant for PG 10
> and PG 11, because we don't recommend using so many partitions with
> them.  Maybe we can consider fixing PG 12 though.

A fix for the thousands-of-partitions case would be very welcome for 12.


Look like commit # d3f48dfae42 added the required fix but is enabled only for
the clobber-cache builds :(

Regards,
Amul


pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Global temporary tables
Next
From: Antonin Houska
Date:
Subject: Re: Converting NOT IN to anti-joins during planning