From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: Alexander Lakhin <exclusion@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17855: Uninitialised memory used when the name type value
 processed in binary mode of Memoize
In-reply-to: 
 <CAApHDvqqvkorexCuVkSJ16LcqGKfUdLAn3Y+YsqKNT3Pe56oOA@mail.gmail.com>
References: <17855-5f523e0f9769a566@postgresql.org>
 <CAApHDvqwwdO1EAo-6osu-LtTk1SD2iQjLQXhVd7Wamc-JfhfrQ@mail.gmail.com>
 <CAApHDvokmLEriy3+4vB0KjCQip5pMq0g_JJX-wHNDvBJKukr6w@mail.gmail.com>
 <CAApHDvqNo_7yipfLjVXatUUosEkKZrdhHxAObPuxSat8UQaUTw@mail.gmail.com>
 <b2a382d6-d261-fdb6-176c-d0cdbf63dce8@gmail.com>
 <CAApHDvqqvkorexCuVkSJ16LcqGKfUdLAn3Y+YsqKNT3Pe56oOA@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Wed, 24 Apr 2024 14:25:56 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3943231.1714060238.1@sss.pgh.pa.us>
Date: Thu, 25 Apr 2024 11:50:38 -0400
Message-ID: <3943232.1714060238@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3943232.1714060238%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> I've attached another patch which uses another method to fix this, per
> an idea from Andres Freund.  I'd class it as a hack, but I don't have
> any better ideas aside from the mammoth task of making name variable
> length.  Indexes on name typed columns simply don't store all 64 bytes
> of the name, so it's not safe to have code that assumes a name Datum
> points to 64 bytes. The patch makes it so such a Datum *will* point to
> 64 bytes.  I've tried to do this as cheaply as possible by saving the
> indexes to name columns in a new array in IndexOnlyScanState.  That
> should make the overhead very small when indexes don't contain any
> name-typed columns.

I realize that this is just a draft patch, but the near-total lack
of comments is still disappointing.  Even at the draft stage,
good comments are important to make it reviewable.

I do not like testing "atttypid == NAMEOID" one bit.  As noted,
that will fail on domains over name.  It will also result in
unnecessary work when reading non-btree indexes that contain
name, since I don't think anything else has the same hack
that btree name_ops does (grep for cstring in pg_opclass.dat).
I think the correct thing is to see whether the index opclass
for the column is btree name_ops.  We don't seem to have an
oid_symbol macro for that, but it shouldn't be hard to add,
at least in HEAD.

			regards, tom lane