Re: Unclear\mistakable description of UPDATE behaviour in "13.2.1. Read Committed Isolation Level"

Hi, David!

Thanks for the explanation!
Now I clearly understand how it works.

I still think it would be great if this doc point was worded a little
differently in new editions.

Thank you!

On Wed, 18 Aug 2021 at 02:03, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Tue, Aug 17, 2021 at 3:56 PM PG Doc comments form <
> noreply(at)postgresql(dot)org> wrote:
>
>>
>> "UPDATE, DELETE, SELECT FOR UPDATE, and SELECT FOR SHARE commands ...
>> ...If the first updater commits, the second updater will ignore the row if
>> the first updater deleted it, otherwise it will attempt to apply its
>> operation to the updated version of the row. The search condition of the
>> command (the WHERE clause) is re-evaluated to see if the updated version
>> of
>> the row still matches the search condition."
>>
>> described in documentation ("The search condition of the command (the
>> WHERE
>> clause) is re-evaluated")
>>
>>
> Maybe the nuance was lost and the docs could be improved, but it clearly
> says "...to see if the updated version of the rows STILL MATCHES the search
> condition" - i.e., it will happily skip a row it thought, before it started
> waiting, that it was going to have to update but it will not go looking for
> new rows that now may match the criteria. It also won't handle any inserts
> by the same reasoning. This is reinforced by the leading sentence:
>
> "...they will only find target rows that were committed as of the command
> start time."
>
> David J.
>

--
with best regards,
radiodiversion