| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tender Wang <tndrwang(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 02:09:38 |
| Message-ID: | CAApHDvreF-UiqBaHtRTQWQ6z1X9snstJW+dfb2DU5GOb-uPEBg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
David
| Attachment | Content-Type | Size |
|---|---|---|
| hack_to_fix_datum_image_problem.patch | application/octet-stream | 1.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xuneng Zhou | 2026-03-25 02:10:05 | Re: log_checkpoints: count WAL segment creations from all processes |
| Previous Message | Michael Paquier | 2026-03-25 02:07:08 | Re: Track skipped tables during autovacuum and autoanalyze |