Re: default partition and concurrent attach partition

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, hawu@vmware.com
Date: 2020-09-07T23:44:27Z
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



Commits

  1. Check default partitions constraints while descending