Re: existing row not found by SELECT ... WHERE CTID = ?

From: Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
To: Matthias Apitz <guru(at)unixarea(dot)de>
Cc: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: existing row not found by SELECT ... WHERE CTID = ?
Date: 2022-05-25 12:27:50
Message-ID: Yo4gxgkAIdqVkMS6@elch.exwg.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

## Matthias Apitz (guru(at)unixarea(dot)de):

> We will solve the problem now with setting the session after connect to
>
> SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL REPEATABLE READ;
>
> (with an appropriate ESQL/C call). Any comments?

Maybe the real question is whether it is wise to use an implementation
artifact (ctid) to identify rows?
The textbook approach could be row locks (SELECT ... FOR SHARE/UPDATE and
variants) to prevent concurrent changes or optimistic locking (and a
primary key in any case) - but maybe you already investigated those options?

Regards,
Christoph

--
Spare Space

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Färber 2022-05-25 12:55:36 Extension pg_trgm, permissions and pg_dump order
Previous Message Matthias Apitz 2022-05-25 12:01:12 Re: existing row not found by SELECT ... WHERE CTID = ?