On Fri, Jun 15, 2001 at 10:21:37AM -0400, Tom Lane wrote:
> "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.
An simpler alternative was change all "sufficiently old" tuples to have
an xmin value, N, equal to the oldest that would need to be distinguished.
xmin values could then be compared using normal arithmetic: less(xminA,
xminB) is just ((xminA - N) < (xminB - N)), with no special cases.
> 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.)
That assumes a pretty frequent system restart. Many of us prefer
to code to the goal of a system that could run for decades.
Nathan Myers
ncm@zembu.com
