On Mon, Feb 20, 2017 at 04:22:51PM -0500, Tom Lane wrote:
> One other thought here --- if you do want to go with the "no other
> updates" semantics, it still seems like it should be sufficient to
> compare xmins. Comparing the xmax values would add nothing to that,
> except that it would reject i
Karsten Hilbert writes:
> Also a consideration: table.*::text may become quite unwieldy
> if there's one or more BYTEA columns in the table.
One other thought here --- if you do want to go with the "no other
updates" semantics, it still seems like it should be sufficient to
compare xmins. Compar
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 col
Rakesh Kumar 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
>
On Mon, Feb 20, 2017 at 07:27:34PM +, Rakesh Kumar wrote:
> I tested it and it works. what I did was to select xmin and xmax and then
> sleep for a min.
> In the meantime, I update the same row in another session.
> After 1 min the update session failed to update any row because the
> combi
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
