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 по дате отправления: