From: | "Dave Cramer" <dave(at)fastcrypt(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Henshall, Stuart - WCP" <SHenshall(at)westcountrypublications(dot)co(dot)uk>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RE: Row Versioning, for jdbc updateable result sets |
Date: | 2001-06-15 15:50:32 |
Message-ID: | 001d01c0f5b2$e8c6cb60$0201a8c0@INSPIRON |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-06-15 16:27:02 | Re: Encrypting pg_shadow passwords |
Previous Message | Doug McNaught | 2001-06-15 15:40:41 | Re: UNIQUE INDEX unaware of transactions |