Re: Postgres 16.1 - Bug: cache entry already complete

Amadeo Gallardo <amadeo@ruddr.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