Re: Error from array_agg when table has many rows
От | David Rowley |
---|---|
Тема | Re: Error from array_agg when table has many rows |
Дата | |
Msg-id | CAApHDvrsJ6qhgpjW2HNe8UbDkzZOdKQ=rDjeynswnce7LtWCxQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Error from array_agg when table has many rows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Error from array_agg when table has many rows
|
Список | pgsql-bugs |
On Sun, 9 Mar 2025 at 04:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Richard Guo <guofenglinux@gmail.com> 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. The only way I can think of to get that would be to special-case array_agg_serialize() to have it serialize the typmod when the send function is record_send(), then add a similar special-case to array_agg_deserialize() to check for a record_recv() and deserialize the typmod there. That doesn't seem very pretty, so I'm happy to go with your fix to disable parallel aggregates for this case. David
В списке pgsql-bugs по дате отправления: