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  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
Список 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 по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Using CTID system column as a "temporary" primary key
Следующее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: Using CTID system column as a "temporary" primary key