Row versioning

Started by Ruediger Herrmannover 21 years ago4 messagesgeneral
Jump to latest
#1Ruediger Herrmann
ruediger.herrmann@gmx.de

Hi all,

has anyone implemented row versions/timestamps in PostgreSQL or any
thoughts on this?
Did I hit the right term? What I want to achieve is optimistic
concurrency beyound transaction boundaries. When retrieving data
I would also retrieve the row version and later on, in a different
transaction, before updating the data, I could check if was unchanged.
(row version at read time = row version at update time)

What are the pro's and con's about adding a "sequence" row that is
incremented by a trigger each time the row is updated?
Is having a timestamp row instand better?

Regards
Ruediger

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD
++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ruediger Herrmann (#1)
Re: Row versioning

"Ruediger Herrmann" <ruediger.herrmann@gmx.de> writes:

has anyone implemented row versions/timestamps in PostgreSQL or any
thoughts on this?
Did I hit the right term? What I want to achieve is optimistic
concurrency beyound transaction boundaries. When retrieving data
I would also retrieve the row version and later on, in a different
transaction, before updating the data, I could check if was unchanged.

You could use the xmin system column for this.

regards, tom lane

#3Ruediger Herrmann
ruediger.herrmann@gmx.de
In reply to: Tom Lane (#2)
Re: Row versioning

thanks for your replay. This approach sounds very comfy. As I read the
documentation this is kind of a "transaction sequence" or better a
"unique transaction id". Am I right with this? So every row inserted or
updated within the same transaction is tagged with the same xmin.

Is there any information wether this approach is future proof? I heard
the OID is depecated now, maybe XMIN is next, no idea...

TIA
Ruediger

has anyone implemented row versions/timestamps in

PostgreSQL or any

thoughts on this?
Did I hit the right term? What I want to achieve

is optimistic

concurrency beyound transaction boundaries. When

retrieving data

I would also retrieve the row version and later

on, in a different

transaction, before updating the data, I could

check if was unchanged.

You could use the xmin system column for this.

regards, tom lane

-- 
Geschenkt: 3 Monate GMX ProMail + 3 Ausgaben der TV Movie mit DVD
++++ Jetzt anmelden und testen http://www.gmx.net/de/go/mail ++++
#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Ruediger Herrmann (#3)
Re: Row versioning

"Ruediger Herrmann" <ruediger.herrmann@gmx.de> writes:

Is there any information wether this approach is future proof?

[ shrug... ] As much as anything that's not specified by the SQL
standard is around here. We have no plans to replace MVCC, and
xmin/xmax are a pretty fundamental part of that.

regards, tom lane