Re: [GENERAL] Using xmin and xmax for optimistic locking - Mailing list pgsql-general

From Karsten Hilbert
Subject Re: [GENERAL] Using xmin and xmax for optimistic locking
Date
Msg-id 20170220205650.7xv44r6o5uhnqmwd@hermes.hilbert.loc
Whole thread Raw
In response to Re: [GENERAL] Using xmin and xmax for optimistic locking  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Using xmin and xmax for optimistic locking  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Mon, Feb 20, 2017 at 03:44:49PM -0500, Tom Lane wrote:

> >    where table.*::text = (saved from select).
>
> > If the row was changed between the time it was first read and updated, the
> > update will do touch any rows as the ::text will be different.
>
> > Why can't we use xmin and xmax columns to achieve the same.
>
> Well, that doesn't do quite the same thing: the cookbook query will
> proceed if there was a no-op update in between (or maybe even two updates
> that canceled each other out).  If you look at xmin then you won't proceed
> in such cases.  I could imagine either behavior being "right" depending on
> your application needs.

Also a consideration: table.*::text may become quite unwieldy
if there's one or more BYTEA columns in the table.

Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


pgsql-general by date:

Previous
From: Adam Brusselback
Date:
Subject: Re: [GENERAL] Search on very big (partitioned) table
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Using xmin and xmax for optimistic locking