Re: lifetime of the old CTID

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: lifetime of the old CTID
Date: 2022-07-06 09:48:08
Message-ID: YsVaWIma6SrZNGEo@hermes.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Am Wed, Jul 06, 2022 at 08:41:58AM +0200 schrieb Laurenz Albe:

> Using the primary key is the proper solution. To be safe from concurrent
> modifications, use a logic like in this pseudo-code:
>
> FOR b IN SELECT pk, other_columns FROM books WHERE condition
> UPDATE books SET ... WHERE pk = ... AND condition
>
> Checking the condition again on the inner UPDATE will detect concurrent
> data modifications. If the UPDATE changes nothing, then a book has been
> removed or updated by a concurrent transaction, and you ignore it.

UPDATEing conditional on XMIN not having changed might be
another solution for detecting concurrent transacations if
one is bent on using system columns for that.

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Florents Tselai 2022-07-06 09:48:34 Re: ADD COLUMN ts tsvector GENERATED too slow
Previous Message Karsten Hilbert 2022-07-06 09:45:14 Re: lifetime of the old CTID