Re: RE: Row Versioning, for jdbc updateable result sets

"Dave Cramer" <dave@fastcrypt.com> writes:
> I had no idea that xmin even existed, but having a quick look I think this
> is what I am looking for. Can I assume that if xmin has changed, then
> another process has changed the underlying data ?

xmin is a transaction ID, not a process ID, but looking at it should
work for your purposes at present.

There has been talk of redefining xmin as part of a solution to the
XID-overflow problem: what would happen is that all "sufficiently old"
tuples would get relabeled with the same special xmin, so that only
recent transactions would need to have distinguishable xmin values.
If that happens then your code would break, at least if you want to
check for changes just at long intervals.

A hack that comes to mind is that when relabeling an old tuple this way,
we could copy its original xmin into cmin while setting xmin to the
permanently-valid XID.  Then, if you compare both xmin and cmin, you
have only about a 1 in 2^32 chance of being fooled.  (At least if we
use a wraparound style of allocating XIDs.  I think Vadim is advocating
resetting the XID counter to 0 at each system restart, so the active
range of XIDs might be a lot smaller than 2^32 in that scenario.)
        regards, tom lane