From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amadeo Gallardo <amadeo@ruddr.io>
cc: pgsql-bugs@lists.postgresql.org, David Rowley <dgrowleyml@gmail.com>
Subject: Re: Postgres 16.1 - Bug: cache entry already complete
In-reply-to: 
 <CADFREbVAApY+zq7ep=4VeLwb30QAk5mrAd0xnNeqq63Ec8m1hA@mail.gmail.com>
References: 
 <CADFREbW-BLJd7-a5J+5wjVumeFG1ByXiSOFzMtkmY_SDWckTxw@mail.gmail.com>
 <4103444.1704216682@sss.pgh.pa.us>
 <CADFREbWeAhTHwCOunhXJiBEsjyZfmhCdX2=VswQ5XVwNm8JYqQ@mail.gmail.com>
 <CADFREbVAApY+zq7ep=4VeLwb30QAk5mrAd0xnNeqq63Ec8m1hA@mail.gmail.com>
Comments: In-reply-to Amadeo Gallardo <amadeo@ruddr.io>
	message dated "Tue, 02 Jan 2024 20:48:58 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <91858.1704240330.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 02 Jan 2024 19:05:30 -0500
Message-ID: <91859.1704240330@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/91859.1704240330%40sss.pgh.pa.us>
Precedence: bulk

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=3D0.46..82.87 rows=3D315 width=3D1)
   Join Filter: (t3.t2_id =3D t2.id)
   ->  Nested Loop Left Join  (cost=3D0.30..32.29 rows=3D315 width=3D32)
         ->  Nested Loop Left Join  (cost=3D0.15..17.29 rows=3D315 width=3D=
32)
               ->  Seq Scan on t4  (cost=3D0.00..6.15 rows=3D315 width=3D3=
2)
               ->  Memoize  (cost=3D0.15..0.19 rows=3D1 width=3D16)
                     Cache Key: t4.t2_id
                     Cache Mode: logical
                     ->  Index Only Scan using t2_pkey on t2  (cost=3D0.14=
..0.18 rows=3D1 width=3D16)
                           Index Cond: (id =3D t4.t2_id)
         ->  Memoize  (cost=3D0.15..0.20 rows=3D1 width=3D16)
               Cache Key: t4.t1_id
               Cache Mode: logical
               ->  Index Only Scan using t1_pkey on t1  (cost=3D0.14..0.19=
 rows=3D1 width=3D16)
                     Index Cond: (id =3D t4.t1_id)
   ->  Memoize  (cost=3D0.16..0.55 rows=3D1 width=3D33)
         Cache Key: t1.id, t1.id
         Cache Mode: logical
         ->  Index Scan using t3_t1_id_index on t3  (cost=3D0.15..0.54 row=
s=3D1 width=3D33)
               Index Cond: (t1_id =3D 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