Horton

Re: BUG #17912: Invalid memory access when converting plpython' array containing empty array

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-04-30T16:24:38Z
Lists: pgsql-bugs

Attachments

Alexander Lakhin <exclusion@gmail.com> writes:
> 29.04.2023 20:16, Tom Lane wrote:
>> I'm a little uncomfortable with changing the semantics of non-failing
>> cases in the back branches.

> I agree that we shouldn't introduce a new behavior in the released branches.
> For that moment I was thinking about the choice between v16 and v17
> for that patch to be committed to.
> But as you see the better solution now, the patch will be different and more
> extensive, I suppose, so I'd vote for postponing it for v17.

Here's a version that adopts plperl's logic, causing it to treat
empty sub-lists as being zero-length dimensions.  Most of the new
test cases are borrowed from plperl, too, and most of them act
differently before and after the code change.  So I'm pretty
hesitant to put this into stable branches.  OTOH, maybe it's not
too late for v16?

I noticed one inarguable bug here, too: PLySequence_ToArray_recurse
leaks Python object refcounts after errors, because it has no
PG_TRY to ensure that Py_XDECREF() gets done.  I'm not sure if
it's worth doing something about that in the back branches, given
the lack of complaints.

			regards, tom lane

Commits

  1. Tighten array dimensionality checks in Python -> SQL array conversion.

  2. Tighten array dimensionality checks in Perl -> SQL array conversion.

  3. Handle zero-length sublist correctly in Python -> SQL array conversion.