Re: Postgres 16.1 - Bug: cache entry already complete

Amadeo Gallardo <amadeo(at)ruddr(dot)io> writes:
> 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.

Thanks! EXPLAIN shows

QUERY PLAN
------------------------------------------------------------------------------------------------
Nested Loop Left Join (cost=0.46..82.87 rows=315 width=1)
Join Filter: (t3.t2_id = t2.id)
-> Nested Loop Left Join (cost=0.30..32.29 rows=315 width=32)
-> Nested Loop Left Join (cost=0.15..17.29 rows=315 width=32)
-> Seq Scan on t4 (cost=0.00..6.15 rows=315 width=32)
-> Memoize (cost=0.15..0.19 rows=1 width=16)
Cache Key: t4.t2_id
Cache Mode: logical
-> Index Only Scan using t2_pkey on t2 (cost=0.14..0.18 rows=1 width=16)
Index Cond: (id = t4.t2_id)
-> Memoize (cost=0.15..0.20 rows=1 width=16)
Cache Key: t4.t1_id
Cache Mode: logical
-> Index Only Scan using t1_pkey on t1 (cost=0.14..0.19 rows=1 width=16)
Index Cond: (id = t4.t1_id)
-> Memoize (cost=0.16..0.55 rows=1 width=33)
Cache Key: t1.id, t1.id
Cache Mode: logical
-> Index Scan using t3_t1_id_index on t3 (cost=0.15..0.54 rows=1 width=33)
Index Cond: (t1_id = t1.id)
(20 rows)

It's that last Memoize node with the duplicate cache keys that is
failing. (It's unclear to me whether having duplicate cache keys
is supposed to be a valid situation, and even less clear whether
that has any direct connection to the failure.) What I guess
is happening is that the single-row flag is getting set because
t1.id is a primary key, despite the fact that it's coming from
inside a join that could result in duplicates.

regards, tom lane