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
Date: Tue, 02 Jan 2024 19:05:30 -0500
Message-ID: <91859.1704240330@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, amadeo@ruddr.io, dgrowleyml@gmail.com
Subject: Re: Postgres 16.1 - Bug: cache entry already complete
In-Reply-To: <91859.1704240330@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox