On Thu, 23 Mar 2023 at 16:10, David Rowley <dgrowleyml@gmail.com> wrote:
> Right now, I don't have any bright ideas on how we might fix this.
> The only thing I can think of right now is to adjust StoreIndexTuple()
> to check for mismatching data types and if it finds one, convert with
> the index type's output function and import with the heap type's input
> function. Sounds like painful overhead not to mention how to manage
> the memory allocations so it does not leak any copied Datum values.
I had a bit of an offline chat about this bug to Andres. We talked
about the method described in the above paragraph as a means to fix
this.
We talked about the possibilities of bugs being a bit more widespread.
For example, anywhere that does datumCopy() (i.e. lots of places) on a
name type could read too many bytes.
I've drafted up a patch which adds some code to nodeIndexonlyscan.c.
During ExecInitIndexOnlyScan() to looks for any name types in the
scan's tupleDesc and if it finds some, it marks the position of each
of these in a new array in IndexOnlyScanState. When we call
StoreIndexTuple(), if that array has any elements, we spin through it
and convert the cstring names to Names correctly padded out to
64-bytes.
The attached is just a draft so far. It'll need more comments to
document what the code is all about. I don't want to spend too much
time on it if this isn't going to be the final solution.
I'd be happy to hear from anyone who has any thoughts on this as a fix
for the issue.
David