Re: pointless check in RelationBuildPartitionDesc

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: pointless check in RelationBuildPartitionDesc
Дата
Msg-id 380c6b65-8b7f-d8c4-828f-715be111d781@lab.ntt.co.jp
обсуждение исходный текст
Ответ на pointless check in RelationBuildPartitionDesc  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: pointless check in RelationBuildPartitionDesc  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 2018/09/04 6:39, Alvaro Herrera wrote:
> I noticed this strange hack in RelationBuildPartitionDesc:
> 
>        /*
>         * It is possible that the pg_class tuple of a partition has not been
>         * updated yet to set its relpartbound field.  The only case where
>         * this happens is when we open the parent relation to check using its
>         * partition descriptor that a new partition's bound does not overlap
>         * some existing partition.
>         */
>        if (!((Form_pg_class) GETSTRUCT(tuple))->relispartition)
>        {
>            ReleaseSysCache(tuple);
>            continue;
>        }
> 
> After looking, it seems that this is just self-inflicted pain: for some
> reason, we store the pg_inherits row for a partition, and immediately
> afterwards compute and store its partition bound, which requires the
> above hack.  But if we do things in the opposite order, this is no
> longer needed.  I propose to remove it, as in the attached patch.

+1.  I remember having facepalmed at this before and had also written a
patch but never got around to submitting it.

Thanks,
Amit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Restricting maximum keep segments by repslots
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Slotification of partition tuple conversion