Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2023-03-22T03:07:15Z
Lists: pgsql-bugs
On Tue, Mar 21, 2023 at 10:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alexander Lakhin <exclusion@gmail.com> writes: > > I'm afraid that zeroing only bytes behind nitems bits is not enough, as > outDatum() doesn't bother to calculate the exact > > size of nulls bitmap, it just outputs all bytes of a datum (40 bytes in > that case): > > In that case, won't padding bytes between array elements also create > issues? Seems like we have to just zero the whole array area, like > those other functions do. Yeah, this should be the right fix, to use palloc0 instead here. FWIW currently in the codes there are 14 places that explicitly allocate ArrayType, 13 of them using palloc0, the only exception is the one discussed here. BTW, in array_set_slice() and array_set_element() we explicitly zero the null bitmap although the whole array area is allocated with palloc0. Is this necessary? Thanks Richard
Commits
-
Fix oversights in array manipulation.
- ae320fc21686 11.20 landed
- ad5fe7420594 12.15 landed
- 7c4873438fd4 15.3 landed
- 554841699f0e 16.0 landed
- 1bbbe14607c3 13.11 landed
- 11213d44663e 14.8 landed
-
Fix array- and path-creating functions to ensure padding bytes are zeroes.
- 18c0b4eccdc8 9.1.0 cited