Re: Patch: show relation and tuple infos of a lock to acquire

Alvaro Herrera escribió:

> Another thing that jumped at me is that passing a TID but not a Relation
> is fairly useless as it stands.  We might try to add some more stuff
> later, such as printing tuple contents as previous versions of the patch
> did, but given the opposition the idea had previously, I'm not sure
> that's ever going to happen.  If we decide that TID-but-not-Relation is
> not a useful case, then we can trim the number of messages to translate.

Andres and I chatted a bit about this and came to these conclusions:

1. MyProcPort contains the database name; no need for the
get_database_name() call in there.

2. Since this is dealing with tuples obtained from tables, it's hard to
see a case where there would be no table or no database.  (What does a
TID mean without an accompanying relation, anyway?)

3. The MyProcPort thing is initialized quite early in the startup
sequence.  I don't think it's possible to get to a tuple-lock wait
without having the database initialized.

Therefore I think the only case worth considering here is when
database/relation/TID are all defined.  The other cases where there is
partial information are dead code; and the case where there is nothing
defined (such as the one in SnapBuildFindSnapshot) is already handled by
simply not setting up a context at all.


4. There are a few extant get_database_name(MyDatabaseId) calls that
could presumably be replaced by MyProcPort->database_name.  Or if we
want to get cute, hack get_database_name so that if dbid == MyDatabaseId
return MyProcPort->database_name.  (This would also affect callers of
get_database_name that use a value not hardcoded to MyDatabaseId).

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services