El día Wednesday, May 25, 2022 a las 11:21:44AM +0200, Matthias Apitz escribió:
> El día martes, mayo 24, 2022 a las 12:11:49 -0400, Tom Lane escribió:
>
> > Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > > 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.
> >
> > Even without HOLD, a cursor will return a view of the data as it stood
> > when the cursor was opened, just as a plain SELECT does. There is
> > *plenty* of time for another session to get in there if you've been
> > groveling through 50K records one at a time.
>
> Tom, Thanks for pointing us in the right direction where to look for a
> solution. The CURSOR was opened around 23:11 pm and the CTID not found
> at 23:21 pm, i.e. ten minutes later. This piece of software does every
> night some housekeeping work in the circulation area of our LMS (Library
> Management System) and is meant to run as a standalone job (only one
> process after the other). We're trying to figure out with the customer if something
> else was started/running at this time between 23:11 and 23:21, to shut this
> off in the future. ...
Is there any way to get with the old CTID to the row, for example with
the old CTID to the new one which the row now has after the update of the row?
matthias
--
Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
