On Tue, 2002-04-23 at 12:52, Martijn van Oosterhout wrote:
> Well, from my thinking about how you would use these fields in a logical
> way, it seems it's possible for xmax to be non-zero if the transaction
> numbered xmax was not committed. But in that case (unless it was a delete)
> there would be a newer tuple with the same oid but xmax == 0 (and this
> uncommitted transaction as xmin).
Unless it was an uncommitted DELETE and not UPDATE.
> The problem is that inside the DB, you have a current transaction plus a
> list of committed transactions. Externally, you have no idea, so xmax == 0
> is as valid a view as any other. This would have the effect of dumping out
> whatever would be visible if every transaction were committed.
IIRC there are some bits that determine the commit status of tuple.
> I think. If anyone knows a good document on MVCC implementations, let me
> know.
>
> > But I think the most useful behaviour should be to dump system fields
> > too, so mildly knowledgeable sysadmin can import the dump and do the
> > right thing afterwards (like restore data as it was before transaction
> > nr 7000)
>
> Well, i didn't think you could have statements of the form:
>
> insert into table (xmin,xmax,cmin,cmax,...) values (...);
but you can have
insert into newtable values (...);
So you are free to name your xmin,... whatever you like
> So you would have to leave it as a comment. In which case someone would have
> to go and by hand work out what would be in or out. I can make it an option
> but I don't think it would be particularly useful.
I have written a small python script that does the above, and I did
write it because I needed it, so it must have some use ;)
After inserting the data to database I was then able to select all but
latest (before delete) version of each tuple.
--------------
Hannu
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
