From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | "Inoue, Hiroshi" <inoue(at)tpf(dot)co(dot)jp> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: [HACKERS] getting rid of SnapshotNow |
Date: | 2013-07-19 13:03:30 |
Message-ID: | 20130719130330.GI20525@alap2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-odbc |
On 2013-07-19 08:57:01 +0900, Inoue, Hiroshi wrote:
> >>I had the idea they were used for a client-side implementation of WHERE
> >>CURRENT OF. Perhaps that's dead code and could be removed entirely?
> >
> >It's been reported that ODBC still uses them.
>
> Though PostgreSQL's TID is similar to Orale's ROWID, it is transient
> and changed after update operations unfortunately. I implemented
> the currtid_xx functions to supplement the difference. For example
>
> currtid(relname, original tid)
>
> (hopefully) returns the current tid of the original row when it is
> updated.
That is only guaranteed to work though when you're in a transaction old
enough to prevent removal of the old or intermediate row versions. E.g.
BEGIN;
INSERT INTO foo...; -- last tid (0, 1)
COMMIT;
BEGIN;
SELECT currtid(foo, '(0, 1'));
COMMIT;
can basically return no or even an arbitrarily different row. Same with
an update...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Samrat Revagade | 2013-07-19 13:20:38 | Re: Using ini file to setup replication |
Previous Message | Robert Haas | 2013-07-19 12:55:47 | Re: getting rid of SnapshotNow |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-07-19 13:35:49 | Re: [HACKERS] getting rid of SnapshotNow |
Previous Message | Robert Haas | 2013-07-19 12:55:47 | Re: getting rid of SnapshotNow |