Re: Using CTID system column as a "temporary" primary key
От | Laurenz Albe |
---|---|
Тема | Re: Using CTID system column as a "temporary" primary key |
Дата | |
Msg-id | f85a1d70ee8f9df8ec7be46cec623f11b43e4fb4.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Using CTID system column as a "temporary" primary key (Sebastien Flaesch <sebastien.flaesch@4js.com>) |
Ответы |
Re: Using CTID system column as a "temporary" primary key
|
Список | pgsql-general |
On Wed, 2023-03-29 at 14:23 +0000, Sebastien Flaesch wrote: > From: Laurenz Albe <laurenz.albe@cybertec.at> > > It is safe to assume that the CTID is stable within a single transaction > > only if you use REPEATABLE READ or better transaction isolation level. > > > > With READ COMMITTED, you see updated rows (and consequently changed CTID) > > within a single transaction. And if you use SELECT ... FOR UPDATE, you > > could even see a changed CTID within a single statement. > > > > So don't use CTID to identify rows unless you use REPEATABLE READ or better. > > Thanks for the advice about REPEATABLE READ isolation level! ... but that is only useful in a read-only scenario. If you try to UPDATE the row in a REPEATABLE READ transaction, you will get a serialization error if there was a concurrent update. In short: don't use the CTID to identify a row. Yours, Laurenz Albe
В списке pgsql-general по дате отправления: