Hi, In ExecEvalConvertRowtype(), if the input row doesn't require any conversion, we simply return that row as is. 2820 /* 2821 * No-op if no conversion needed (not clear this can happen here). 2822 */ 2823 if (op->d.convert_rowtype.map == NULL) 2824 return;
If the type of input row is different from that of the output row, the tree further up would expect typeid in the tuple header to be that of the output row. Rajkumar reported a crash while testing with multi-level partition-wise join with a SELECT clause containing the whole row reference. In case of multi-level partitioning, per the latest proposed patch in [1] a whole-row reference on parent translates into a nested ConvertRowtypeExpr with as many ConvertRowtypeExpr decorations as there are levels in the partitioning hierarchy. Each ConvertRowtypeExpr converts a row from lower partition to the row type of parent. Since the tuples returned by lower ConvertRowtypeExpr were not stamped with output type, following assertion in the same function tripped. 2800 Assert(HeapTupleHeaderGetTypeId(tuple) == indesc->tdtypeid || 2801 HeapTupleHeaderGetTypeId(tuple) == RECORDOID); I tried to create a testcase where this assertion would fail without multi-level partitioned table, but could not construct one. But I think this looks like a bug. PFA the patch to fix this issue by copying the tuple with the output type stamped in tuple header. Since the tuple could be an on-disk tuple, it looks like copying is inevitable. But I am not sure if this is the right fix or if there is any other way to avoid copying. Comments are welcome. [1] https://www.postgresql.org/message-id/CAFjFpRfBipiEzP739PFDrzxrWG-UKThHj3tyHkwCeE2hDwP78A%40mail.gmail.com -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
ConvertRowtypeNoop.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
