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

Tom,

I am considering coding this into postgres's jdbc driver, as there are alot
of requests for updateable rowsets. I really don't want to code this in;
only to have it break later. Is there a way to do this? Can the version # of
the row be made available to the client?

Dave

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dave Cramer" <dave(at)fastcrypt(dot)com>
Cc: "Henshall, Stuart - WCP" <SHenshall(at)westcountrypublications(dot)co(dot)uk>;
<pgsql-hackers(at)postgresql(dot)org>
Sent: Friday, June 15, 2001 10:21 AM
Subject: Re: [HACKERS] RE: Row Versioning, for jdbc updateable result sets

> "Dave Cramer" <dave(at)fastcrypt(dot)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
>
>