| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17888: Incorrect memory access in gist__int_ops for an input array with many elements |
| Date: | 2023-06-15 04:53:36 |
| Message-ID: | ZIqZUKZ/PpMfbqXT@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jun 14, 2023 at 01:21:40PM +0900, Michael Paquier wrote:
> Likely that's something we'd better backpatch, to avoid people playing
> with that too much in the back-branches. Thoughts or objections?
Well, we could perhaps revisit the choice of 08ee64e to remove the
LEAF flag from the data stored. However, seeing the lack of
complaints for the past 18 years with users storing large arrays under
gist__int_ops, spending more time on this is not really appealing,
either. Or we would have heard about that because the decompression
immediately breaks for this case.
I have spent some time on that today, and applied what has been
suggested to restrict the usage of this operator when inserting data
for a leaf page, so as the decompression does not get crazy when
retrieving the contents of the leaf pages.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Guo | 2023-06-15 07:12:01 | Re: BUG #17976: Inconsistent results of SELECT using CASE WHEN clause |
| Previous Message | David Rowley | 2023-06-15 04:33:58 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |