On Tue, 2022-05-24 at 16:44 +0200, Matthias Apitz wrote:
> We have a C-written program, written in ESQL/C, of our LMS where the logic
> crawls with FETCH through a hit list and does UPDATE on some rows which
> match certain condition. This works fine for thousands of rows every night,
> but magically sometimes it fails. I have here the part of ESQL/C logs
> when I was able to catch such a case:
>
> The hit list for the FETCHes is built with:
>
> [29858] [23.05.2022 23:11:06:419]: prepare_common on line 1825: name sid_d01buch; query: "SELECT ctid, * from d01buch
WHEREd01status = 4 "
> [29858] [23.05.2022 23:11:06:419]: ecpg_execute on line 2026: query: declare d01buch_scr scroll cursor with hold for
SELECTctid, * from d01buch WHERE d01status = 4 ; with 0 parameter(s) on
> connection sisis
>
> then the CURSOR d01buch_scr is FETCHed some 59537 times, some of the
> rows were updated and here is the failing situation with a good FETCH of
> the row:
I cannot understand many of your log messages, but it seems quite clear that
you are declaring a WITH HOLD cursor.
Such cursors are materialized when the transactoin that creates the cursor
commits, so the result set is "frozen" and does no longer reflect the current
state of the table.
It may well be that somebody deleted or updated a few rows between the time
the cursor was materialized and the time the 50000th row was fetched.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
