Re: unsupportable composite type partition keys

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: unsupportable composite type partition keys
Дата
Msg-id CA+HiwqH7HKEa+bUpF2pSWpRRZV6E0v5YxLWRW2gBQ=WYw8L5oQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: unsupportable composite type partition keys  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: unsupportable composite type partition keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [HACKERS] WAL logging problem in 9.4.3?
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Implementing Incremental View Maintenance