Re: default partition and concurrent attach partition

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: default partition and concurrent attach partition
Дата
Msg-id 20200907234427.GA8292@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: default partition and concurrent attach partition  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: default partition and concurrent attach partition
Список pgsql-hackers
On 2020-Sep-07, Alvaro Herrera wrote:

> Ah, it looks like we can get away with initializing the RRI to 0, and
> then explicitly handle that case in ExecPartitionCheckEmitError, as in
> the attached (which means reindenting, but I left it alone to make it
> easy to read).

Well, that was silly -- this seems fixable by mapping the tuple columns
prior to ExecPartitionCheck, which is achievable with something like

        if (partidx == partdesc->boundinfo->default_index)
        {
            TupleTableSlot *tempslot;

            if (dispatch->tupmap != NULL)
            {
                tempslot = MakeSingleTupleTableSlot(RelationGetDescr(rri->ri_RelationDesc),
                                                                   &TTSOpsHeapTuple);
                tempslot = execute_attr_map_slot(dispatch->tupmap, slot, tempslot);
            }
            else
                tempslot = slot;
            ExecPartitionCheck(rri, tempslot, estate, true);
            if (dispatch->tupmap != NULL)
                ExecDropSingleTupleTableSlot(tempslot);
        }

though this exact incantation, apart from being pretty horrible, doesn't
actually work (other than to fix this specific test case -- it crashes
elsewhere.)

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: A micro-optimisation for walkdir()
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Optimising compactify_tuples()