| 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-30 03:20:33 |
| Message-ID: | CAApHDvo=qkcxc-Lx83XOxkC9xNfp1tkCZ6Z5rQL5L1vXv=+a7Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 25 Mar 2026 at 22:00, Tender Wang <tndrwang(at)gmail(dot)com> wrote:
>
> 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:
> > 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().
I cleaned that method up and pushed it.
Thanks for the report.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2026-03-30 03:21:54 | Re: Adjust error message for CREATE STATISTICS to account for expressions |
| Previous Message | David G. Johnston | 2026-03-30 03:20:20 | Re: docs: warn about post-data-only schema dumps with parallel restore. |