Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> What's the verdict on relaxing the "live tuple's ctid doesn't change
>> rule"?
>
> I think that's unacceptable; it is known that that will break the ODBC
> and JDBC drivers, as well as any other programs that make use of the
> ctid for re-finding a tuple they read earlier in the same transaction.
AFAIK the JDBC driver doesn't use ctid. But ODBC and other programs do.
> We have not only never deprecated client-side use of ctid for this, but
> actively encouraged it, for instance by going out of our way to support
> fast access for queries "WHERE ctid = 'constant'".
The idea I had was to change what the ctid system column returns to
root ctid + xmin + cmin. As long as programs treat the ctid as an opaque
string, it should work. Tid scan would use that to locate the original
tuple.
> What's more, your proposal would break plain old UPDATE and DELETE,
> as well as SELECT FOR UPDATE, none of which promise to hold a pin
> continuously on every page containing a tuple they might decide to
> revisit (by ctid) later. Are you prepared to disallow hash join and
> sort/merge join in all such queries?
No, of course not. We'd have to do the same thing here; use root tid +
xmin + cmin instead of just ctid.
But now that I think of it, how do we get the root tid of a tuple? I
suppose we'd be back to having backpointers or scanning the whole
page... I guess pointer-swinging it is, then.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com