Rakesh Kumar <rakeshkumar...@outlook.com> writes:
> In the chapter "Using optimistic locking" of the book "PG Cookbook Second
> Edition"
> it is mentioned how the app can first fetch row from the table in the form
> select a.*::text from table a where ...
> Then do the work and then when it comes to committing do it as
> update table
> set ....
> 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.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
