Re: Lost update in an ordered batch, but only with index scan

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Bernice Southey <bernice(dot)southey(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Amit Langote <amitlangote09(at)gmail(dot)com>
Subject: Re: Lost update in an ordered batch, but only with index scan
Date: 2025-12-29 08:12:15
Message-ID: CAMbWs4-uC8DWRZvByHej+9E5em7V_+zNyRfFx-UUpR4HwifK4w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Dec 29, 2025 at 8:07 AM Bernice Southey
<bernice(dot)southey(at)gmail(dot)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(at)postgresql(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-12-29 09:13:39 BUG #19367: typos in backend/utils/adt/timestamp.c
Previous Message PG Bug reporting form 2025-12-29 06:00:01 BUG #19366: heap-use-after-free in pgaio_io_reclaim() detected with RELCACHE_FORCE_RELEASE