Re: unsupportable composite type partition keys - Mailing list pgsql-hackers

From Amit Langote
Subject Re: unsupportable composite type partition keys
Date
Msg-id CA+HiwqH7HKEa+bUpF2pSWpRRZV6E0v5YxLWRW2gBQ=WYw8L5oQ@mail.gmail.com
Whole thread Raw
In response to Re: unsupportable composite type partition keys  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: unsupportable composite type partition keys
List pgsql-hackers
On Tue, Dec 24, 2019 at 10:59 AM Amit Langote <amitlangote09@gmail.com> wrote:
> Btw, does the memory leakage fix in this patch address any of the
> pending concerns that were discussed on the "hyrax vs.
> RelationBuildPartitionDesc" thread earlier this year[1]?
>
> [1] https://www.postgresql.org/message-id/flat/3800.1560366716%40sss.pgh.pa.us#092b6b4f6bf75d2f3f90ef6a3b3eab5b

I thought about this a little and I think it *does* address the main
complaint in the above thread.

The main complaint as I understand is that receiving repeated
invalidations due to partitions being concurrently added while a
PartitionDirectory is holding a pointer to PartitionDesc causes many
copies of PartitionDesc to pile up due to the parent table being
rebuilt upon processing of each invalidation.

Now because we don't build the PartitionDesc in the
RelationClearRelation path, that can't happen.  Although it still
seems possible for the piling up to occur if it's
RelationBuildPartitionDesc that is run repeatedly via
RelationGetParttionDesc while partitions are being concurrently added,
but I couldn't find anything in the partitioning code that does that.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Tatsuo Ishii
Date:
Subject: Re: Implementing Incremental View Maintenance