Rakesh Kumar <rakeshkumar464@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
