Re: Fix "could not find memoization table entry"

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix "could not find memoization table entry"
Date: 2026-03-25 09:00:17
Message-ID: CAHewXN=Zzy7kPf3kSkxRzMY9tSZFOt8JRhKW_M_FzLY3px-esQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> 于2026年3月25日周三 10:09写道:
>
> On Wed, 25 Mar 2026 at 13:31, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > Obviously, we don't want to back-patch anything that would cause a
> > user-visible change in the return value of hash_numeric(), so I've
> > been experimenting to see if there's any way to get PostgreSQL to
> > output any value from hash_numeric() larger than 2^31 and I've been
> > unable to. I tried:
>
> I was experimenting with a less risky fix by having the datum_image
> functions force the sign-extended representation of the Datum before
> hashing or comparing.
>
> Attached is a quick PoC of what that would look like. It does fix the
> reported problem. But it is a hack and doesn't fix the root cause of
> the issue.
>
> Despite the hackiness, I feel this might be better than the
> whack-a-mole approach of just fixing incorrect usages of the
> PG_RETURN_* macros as and when we find them.

No objection from me.
It seems no users have complained about hash_numberic(), and except
for this reported issue, no internal errors have been reported due to
hash_numberic().

--
Thanks,
Tender Wang

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2026-03-25 09:00:49 Re: Adding REPACK [concurrently]
Previous Message Peter Eisentraut 2026-03-25 08:57:31 Re: SQL Property Graph Queries (SQL/PGQ)