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
Greetings:
I am working on converting a transportation application from a Progress
database to PostgreSQL. This application will be hammered by about 75 users
at any given time. Also, depending on the operation, there are many record
updates that occur at the trigger level. I would like to be a
