From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls |
Date: | 2023-03-22 03:07:15 |
Message-ID: | CAMbWs4_=kd4-u3Mh3tV+NcHuSGY-9Fax+Ck1ZVzOV0HzJ6dXow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Mar 21, 2023 at 10:24 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Lakhin <exclusion(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2023-03-22 06:18:47 | Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize |
Previous Message | Tom Lane | 2023-03-21 14:24:28 | Re: BUG #17858: ExecEvalArrayExpr() leaves uninitialised memory for multidim array with nulls |