Re: Lost update in an ordered batch, but only with index scan - Mailing list pgsql-bugs

From Richard Guo
Subject Re: Lost update in an ordered batch, but only with index scan
Date
Msg-id CAMbWs4-uC8DWRZvByHej+9E5em7V_+zNyRfFx-UUpR4HwifK4w@mail.gmail.com
Whole thread Raw
In response to Lost update in an ordered batch, but only with index scan  (Bernice Southey <bernice.southey@gmail.com>)
List pgsql-bugs
On Mon, Dec 29, 2025 at 8:07 AM Bernice Southey
<bernice.southey@gmail.com> wrote:
> I've been following the recommendation of ordering batch updates to
> avoid deadlocks. I just added a new case, and it consistently loses
> updates in my tests.

Thanks for the report.  I think this is a bug.  git-bisect shows that:

cbc127917e04a978a788b8bc9d35a70244396d5b is the first bad commit
commit cbc127917e04a978a788b8bc9d35a70244396d5b
Author: Amit Langote <amitlan@postgresql.org>
Date:   Fri Feb 7 17:15:09 2025 +0900

    Track unpruned relids to avoid processing pruned relations

I didn't look further, but it seems like the same bug as reported in
[1].

[1] https://postgr.es/m/19355-57d7d52ea4980dc6@postgresql.org

- Richard



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #19366: heap-use-after-free in pgaio_io_reclaim() detected with RELCACHE_FORCE_RELEASE
Next
From: PG Bug reporting form
Date:
Subject: BUG #19367: typos in backend/utils/adt/timestamp.c