Attached is a sample script that I used to reproduce the error. I had to add some specific sample data and force-disable certain planner settings, as otherwise the problem did not occur.
Additionally, here's a trace of the error:
org.postgresql.util.PSQLException: ERROR: cache entry already complete at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:333) at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:319) at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:295) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:290)
Hopefully this helps to narrow down the issue.
Thanks
On Tue, Jan 2, 2024 at 4:51 PM Amadeo Gallardo <amadeo@ruddr.io> wrote:
Hi Tom,
Thanks for reaching out. So far, I was able to narrow it down to a problem when doing a union between two tables, one of them having a varchar column and the other one having a text column. Adding an explicit cast seems to have fixed it, but not really sure why yet. I will try to create a simple repro scenario.
Amadeo Gallardo <amadeo@ruddr.io> writes: > Upgrading from Postgres 14 to Postgres 16.1 introduced the following error > when running a query:
> nativeError: error: select "date", coalesce(sum(hours), 0) as "hours" from > "allocation_date" where "allocation_date"."project_id" = $1 and > "allocation_date"."date" > $2 and "allocation_date"."hours" > $3 group by > "date" order by "date" asc - cache entry already complete
> Note that `allocation_date` is a fairly complex view. Not quite sure what > causes the "cache entry already complete", but it consistently failed in > both the MacOS and Windows installations.
The only occurrence of that error string is in nodeMemoize.c, so I suppose you've found a bug in Memoize. A bit odd that it doesn't manifest in v14 where Memoize came in. But anyway, can you reduce this to a self-contained test case?
