Horton

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

Alexander Law <exclusion@gmail.com>

View thread View on postgr.es
From: Alexander Lakhin <exclusion@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2023-05-01T12:00:00Z
Lists: pgsql-bugs 
30.04.2023 19:24, Tom Lane wrote:
> 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?

Thanks for the patch!
I've tested the new implementation and found no issues with it — only
rectangular structures are accepted now. The code is straightforward and
very similar to plperl's, so I would not expect that it might bring new
anomalies, which couldn't be seen before.
Thus I don't think that adding it to current master (and possible follow-up
fixing) can take a significant amount of time out of v16+ schedule only.

> 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.

I continue watching the array handling bugs dancing Sirtaki too. Now it's
another asymmetry:
select '{{1},{{2}}}'::int[];
  {{{1}},{{2}}}
but:
select '{{{1}},{2}}'::int[];
  {}

Reproduced on REL_11_STABLE..master.

Best regards,
Alexander

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.