Re: default partition and concurrent attach partition

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, hawu(at)vmware(dot)com
Subject: Re: default partition and concurrent attach partition
Date: 2020-09-07 23:44:27
Message-ID: 20200907234427.GA8292@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-09-08 00:07:51 Re: Optimising compactify_tuples()
Previous Message Tom Lane 2020-09-07 22:53:53 Re: A micro-optimisation for walkdir()