Message-ID: <9cd163da-d096-7e9e-28f6-f3620962a660@gmail.com>
Date: Mon, 1 May 2023 15:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #17912: Invalid memory access when converting plpython' array
 containing empty array
Content-Language: en-US
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
References: <17912-82ceed78731d9cdc@postgresql.org>
 <1392974.1682694846@sss.pgh.pa.us>
 <bf33fe9b-f2f8-5885-aae3-537cd4591386@gmail.com>
 <1440309.1682705916@sss.pgh.pa.us> <1483429.1682709429@sss.pgh.pa.us>
 <5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com>
 <1805878.1682788590@sss.pgh.pa.us>
 <a8dfc214-5445-147e-2ebc-4de43ed56d38@gmail.com>
 <2073074.1682871878@sss.pgh.pa.us>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <2073074.1682871878@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/9cd163da-d096-7e9e-28f6-f3620962a660%40gmail.com>
Precedence: bulk

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