From: | Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: lifetime of the old CTID |
Date: | 2022-07-06 05:58:19 |
Message-ID: | abb051bd-c04e-f00d-9513-9812d05766a4@a-kretschmer.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Am 06.07.22 um 07:54 schrieb Andreas Kretschmer:
>
>
> Am 06.07.22 um 07:44 schrieb Christophe Pettus:
>>
>>> On Jul 5, 2022, at 22:35, Matthias Apitz <guru(at)unixarea(dot)de> wrote:
>>> Internally, in the DB layer, the read_where() builds the row list
>>> matching
>>> the WHERE clause as a SCROLLED CURSOR of
>>>
>>> SELECT ctid, * FROM d01buch WHERE ...
>>>
>>> and each fetch() delivers the next row from this cursor. The functions
>>> start_transaction() and end_transaction() do what their names
>>> suggest and
>>> rewrite_actual_row() does a new SELECT based on the ctid of the
>>> actual row
>>>
>>> SELECT * FROM d01buch WHERE ctid = ... FOR UPDATE
>>> ...
>>> UPDATE ...
>> On first glance, it appears that you are using the ctid as a primary
>> key for a row, and that's highly not-recommended. The ctid is never
>> intended to be stable in the database, as you have discovered. There
>> are really no particular guarantees about ctid values being retained.
>>
>> I'd suggest having a proper primary key column on the table, and
>> using that instead.
>
>
> 100% ACK.
>
> Andreas
>
>
it reminds me somehow on how people used he OID in old times - and now
we removed the OID completely.
Andreas
--
Andreas Kretschmer
Technical Account Manager (TAM)
www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Apitz | 2022-07-06 06:18:42 | Re: lifetime of the old CTID |
Previous Message | Andreas Kretschmer | 2022-07-06 05:54:28 | Re: lifetime of the old CTID |