Martijn,
thanks for your clarification.
> You need to look at it (XMIN) in conjunction with XMAX. A newly insert row has
> XMIN set and XMAX null. When a row is updated the XMAX of the old row
> is set and a new row is created with an XMIN. When you delete a row it
> just sets the XMAX.
But, as y
On Fri, Oct 29, 2004 at 09:22:42AM +0200, Karsten Hilbert wrote:
> The docs say that XMIN is the transaction ID of the *inserting*
> transaction for this row version. IOW updates will change XMIN.
> Will XMIN also be changed by a *deleting* transaction ? I guess
> it depends on how deletion is hand
> > begin;
> > select ... for update;
> > update ... set ... where
> > my_pk=
> > AND
> > xmin=
>
> I think you can skip the SELECT FOR UPDATE altogether if you do it that
> way. Otherwise it looks fine.
Except that there will be other clients accessing those rows,
too, of
Karsten Hilbert <[EMAIL PROTECTED]> writes:
> Just so that I am not getting this wrong:
>> BTW, a handy proxy for "row has not changed" is to see if its XMIN
>> system column is still the same as before.
> Considering that my business objects remember XMIN from when
> they first got the row would t
Just so that I am not getting this wrong:
> BTW, a handy proxy for "row has not changed" is to see if its XMIN
> system column is still the same as before.
Considering that my business objects remember XMIN from when
they first got the row would the following sequence make sure
I am in good shape
Tom,
thanks ! You are even helping lurkers like me that haven't
asked anything :-)
...
> A better design is to fetch the data without locking it, allow the
> user to edit as he sees fit, and then when he clicks "save" you do
> something like
>
> begin;
> select row for update;
>
Thanks for the response on this, especially the tip regarding xmin. I've been
spending much of the night and morning comptemplating this issue. I am glad
to have gotten this information, before going any further. Due to the front
end design, I believe I can implement all this within a short peri
Terry Lee Tucker <[EMAIL PROTECTED]> writes:
> I would like to be able to provide feedback to the user when they
> select a row for update (using SELECT FOR UPDATE). At present, if the
> row is being accessed (with SELECT FOR UPDATE) by another user, the
> application just sits there waiting.
To m
