pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize
Date: Thu, 25 Apr 2024 11:50:38 -0400
Message-ID: <3943232.1714060238@sss.pgh.pa.us> (raw)
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>

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





view thread (19+ messages)  latest in thread

Message-ID: <3943232.1714060238@sss.pgh.pa.us>
Permalink:  ../3943232.1714060238@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3943232.1714060238@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, dgrowleyml@gmail.com, exclusion@gmail.com, 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: <3943232.1714060238@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox