Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqwRU-00CPQy-3u for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Mar 2025 15:50:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tqwRS-0033Pa-NX for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Mar 2025 15:50:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tqwRS-0033N7-E7 for pgsql-bugs@lists.postgresql.org; Sat, 08 Mar 2025 15:50:22 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tqwRL-001hgb-2l for pgsql-bugs@lists.postgresql.org; Sat, 08 Mar 2025 15:50:22 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 528Fo1PL1297402; Sat, 8 Mar 2025 10:50:01 -0500 From: Tom Lane To: Richard Guo cc: David Rowley , Kirill Zdornyy , "pgsql-bugs@lists.postgresql.org" Subject: Re: Error from array_agg when table has many rows In-reply-to: References: Comments: In-reply-to Richard Guo message dated "Sat, 08 Mar 2025 18:38:51 +0900" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1297373.1741448986.0@sss.pgh.pa.us> Date: Sat, 08 Mar 2025 10:50:01 -0500 Message-ID: <1297401.1741449001@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1297373.1741448986.1@sss.pgh.pa.us> Richard Guo writes: > We are performing deserialization during the final phase of the > aggregation on data of type RECORD but we fail to provide a valid > typmod (array_agg_deserialize() uses -1 as the typmod when calling the > receiveproc). > I haven't verified it, but I suspect it's related to 16fd03e95. Yeah. I don't think there is any way for array_agg_deserialize to know the correct typmod, so what we have to do is disable using partial aggregation in this case. Fortunately there's a policy-setting function that can be taught that, as attached. regards, tom lane ------- =_aaaaaaaaaa0 Content-Type: text/x-diff; name="disable_partial_aggregation_on_RECORD.patch"; charset="us-ascii" Content-ID: <1297373.1741448986.2@sss.pgh.pa.us> Content-Description: disable_partial_aggregation_on_RECORD.patch diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c index 9e567f3cc45..0ac8966e30f 100644 --- a/src/backend/parser/parse_agg.c +++ b/src/backend/parser/parse_agg.c @@ -2052,7 +2052,7 @@ resolve_aggregate_transtype(Oid aggfuncid, /* * agg_args_support_sendreceive - * Returns true if all non-byval of aggref's arg types have send and + * Returns true if all non-byval types of aggref's args have send and * receive functions. */ bool @@ -2067,6 +2067,15 @@ agg_args_support_sendreceive(Aggref *aggref) TargetEntry *tle = (TargetEntry *) lfirst(lc); Oid type = exprType((Node *) tle->expr); + /* + * RECORD is a special case: it has typsend/typreceive functions, but + * record_recv only works if passed the correct typmod to identify the + * specific anonymous record type. array_agg_deserialize cannot do + * that, so we have to disclaim support for the case. + */ + if (type == RECORDOID) + return false; + typeTuple = SearchSysCache1(TYPEOID, ObjectIdGetDatum(type)); if (!HeapTupleIsValid(typeTuple)) elog(ERROR, "cache lookup failed for type %u", type); ------- =_aaaaaaaaaa0--