currtid_byreloid and currtid_byrelname

Heikki Linnakangas wrote:

In utils/adt/tid.c, there's two mysterious functions with no comments,
and no-one calling them inside backend code AFAICT: currtid_byreloid
and currtid_byrelname. What do they do/did?

If you have a look at the CVS annotations (
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/tid.c?annotate=1.57
) you can see that they were introduced at version 1.12 (
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/tid.c.diff?r1=1.11;r2=1.12;f=h
)
which has the comment:

The 1st step to implement new type of scan,TidScan.
Now WHERE restriction on ctid is allowed though it is
sequentially scanned.

I often find I have to do this sort of digging to understand what's going on (or find a guilty party :-) ).

cheers

andrew

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:

In utils/adt/tid.c, there's two mysterious functions with no comments, and
no-one calling them inside backend code AFAICT: currtid_byreloid and
currtid_byrelname. What do they do/did?

The comments for heap_get_latest_tid() seem to apply. They're basically
wrappers that open the relation for you since that function requires it. The
real question is why you would ever have a tid without having a Relation
structure handy.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas <heikki@enterprisedb.com> writes:

In utils/adt/tid.c, there's two mysterious functions with no comments,
and no-one calling them inside backend code AFAICT: currtid_byreloid and
currtid_byrelname. What do they do/did?

IIRC, the ODBC driver uses them, or once did, to deal with
concurrent-update situations --- it wants to be able to find the
currently committed version of a row it saw as valid earlier in the
transaction. I think it's sort of a client-side version of the
EvalPlanQual stuff. Hiroshi probably remembers more.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Heikki Linnakangas <heikki@enterprisedb.com> writes:

In utils/adt/tid.c, there's two mysterious functions with no comments,
and no-one calling them inside backend code AFAICT: currtid_byreloid and
currtid_byrelname. What do they do/did?

IIRC, the ODBC driver uses them, or once did, to deal with
concurrent-update situations --- it wants to be able to find the
currently committed version of a row it saw as valid earlier in the
transaction. I think it's sort of a client-side version of the
EvalPlanQual stuff. Hiroshi probably remembers more.

It could be using currtid_byreloid:

List of functions
Schema | Name | Result data type | Argument data types | Owner | Language | Source code | Description
------------+---------+------------------+---------------------+-------+----------+------------------+-----------------------
pg_catalog | currtid | tid | oid, tid | stark | internal | currtid_byreloid | latest tid of a tuple
(1 row)

But how would it use currtid_byrelname?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com