From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize |
Date: | 2024-04-29 00:54:07 |
Message-ID: | CAApHDvpW3ZEyTyogjD6qJsnuTFujLk3yTyCPX-to7VhftkrakQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, 26 Apr 2024 at 03:50, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
On looking at the relcache code, I don't see anywhere that we store
the opclass Oid in RelationData. IndexSupportInitialize() only records
the opcfamily and opcintype. Assuming we can't add new fields to
RelationData in the backbranches, is there a reason why we can't check
for rd_opfamily of TEXT_BTREE_FAM_OID and rd_opcintype of NAMEOID?
I've attached an updated patch that does it that way and also did a
round of commenting the code.
David
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Ensure-we-allocate-NAMEDATALEN-bytes-for-names-in.patch | text/plain | 8.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Javali, Pramod | 2024-04-29 04:33:21 | Unable to connect to server |
Previous Message | Tom Lane | 2024-04-28 01:48:21 | Re: BUG #18449: Altering column type fails when an SQL routine depends on the column |