Re: [HACKERS] currtid_byreloid and currtid_byrelname
"Tom Lane" <[EMAIL PROTECTED]> writes: > Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] currtid_byreloid and currtid_byrelname
Heikki Linnakangas <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] currtid_byreloid and currtid_byrelname
"Heikki Linnakangas" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
