Re: RE: Row Versioning, for jdbc updateable result sets
От | Dave Cramer |
---|---|
Тема | Re: RE: Row Versioning, for jdbc updateable result sets |
Дата | |
Msg-id | 001d01c0f5b2$e8c6cb60$0201a8c0@INSPIRON обсуждение исходный текст |
Ответ на | RE: Row Versioning, for jdbc updateable result sets ("Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>) |
Ответы |
Re: RE: Row Versioning, for jdbc updateable result sets
|
Список | 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@sss.pgh.pa.us> To: "Dave Cramer" <dave@fastcrypt.com> Cc: "Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>; <pgsql-hackers@postgresql.org> Sent: Friday, June 15, 2001 10:21 AM Subject: Re: [HACKERS] 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 > >
В списке pgsql-hackers по дате отправления: