From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Sebastien Flaesch <sebastien(dot)flaesch(at)4js(dot)com>, Kirk Wolak <wolakk(at)gmail(dot)com> |
Cc: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Using CTID system column as a "temporary" primary key |
Date: | 2023-03-29 15:53:08 |
Message-ID: | f85a1d70ee8f9df8ec7be46cec623f11b43e4fb4.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 2023-03-29 at 14:23 +0000, Sebastien Flaesch wrote:
> From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter J. Holzer | 2023-03-29 16:43:37 | Re: Using CTID system column as a "temporary" primary key |
Previous Message | Adrian Klaver | 2023-03-29 14:59:54 | Re: Using CTID system column as a "temporary" primary key |