Re: Is this expected concurrency behaviour for EvalPlanQual and ctid? - Mailing list pgsql-general

From Sophie Alpert
Subject Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?
Date
Msg-id 702bca7b-711f-4d7c-ad39-dead6a628374@app.fastmail.com
Whole thread Raw
In response to Re: Is this expected concurrency behaviour for EvalPlanQual and ctid?  (Bernice Southey <bernice.southey@gmail.com>)
List 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
werefirst retrieved in the same SQL statement, because the ctid can have changed in between the time of the initial
readand the time of locking (and thus the recheck will fail).
 

Sophie



pgsql-general by date:

Previous
From: Thiemo Kellner
Date:
Subject: Re: Top -N Query performance issue and high CPU usage
Next
From: Geoff Winkless
Date:
Subject: Re: UNLOGGED table CREATEd on one connection not immediately visible to another connection