Re: array_agg(anyarray) silently produces corrupt results with parallel workers when inputs mix NULL and non-NULL array elements

Dmytro Astapov <dastapov@gmail.com>

From: Dmytro Astapov <dastapov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2026-04-06T12:04:18Z
Lists: pgsql-bugs

Attachments

On Sat, Apr 4, 2026 at 5:41 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Dmytro Astapov <dastapov@gmail.com> writes:
>


> The initial-setup path is confused about that too, allocating
> newnitems+1 which is pointless.
>

Yes, using newnitems directly is cleaner than my Max() approach, thank you.


>
> It also troubled me that there's no checks for integer overflow
> when calculating the new sizes.


Good catch, I hadn't considered that.


> So I end with the attached revised patch, where I also made one
> or two cosmetic adjustments like putting the type-comparison checks
> next to the dimension comparisons.  Look good to you?
>

Looks good, thank you for improving it.

I built and tested your v2 patch on REL_17_9 and REL_18_3 (with minor
adaptation for the slightly different context lines, like bits8 vs uint8 on
17.x), using the same 10M-row synthetic reproduction from my original
report. They both pass (as expected).

I am attaching the amended patch files for REL_17_9 and REL_18_3 just in
case.

Thank you for the feedback and for the quick turnaround on this!

Best regards, Dmytro

Commits

  1. Fix null-bitmap combining in array_agg_array_combine().

  2. Allow parallel aggregate on string_agg and array_agg