Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?

From: "Sophie Alpert" <pg(at)sophiebits(dot)com>
To: "Bernice Southey" <bernice(dot)southey(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?
Date: 2026-02-05 19:16:29
Message-ID: 702bca7b-711f-4d7c-ad39-dead6a628374@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bernice,

Perhaps you'll find this explanation I wrote around interactions between EvalPlanQual and ctid filters helpful: https://stackoverflow.com/a/79757326/49485

The short answer is that even after my fix, you likely don't want to filter an UPDATE or DELETE on ctid values that were first retrieved in the same SQL statement, because the ctid can have changed in between the time of the initial read and the time of locking (and thus the recheck will fail).

Sophie

In response to

Browse pgsql-general by date

  From Date Subject
Next Message jian he 2026-02-06 03:26:04 Re: Emitting JSON to file using COPY TO
Previous Message Thiemo Kellner 2026-02-05 11:32:03 Re: Top -N Query performance issue and high CPU usage