On Tue, Mar 11, 2014 at 3:53 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > Places where tuple info not available > > LOG: process 5788 still waiting for ShareLock on transaction 679 after > 1014.000 > ms > CONTEXT: while attempting to operate in relation "public"."idx_t1" of > database > "postgres"
The way the context message is assembled piecemeal in XactLockTableWaitErrorContextCallback violates translation guidelines. You need to have completely separate strings for each variant. While attempting to "operate in"? That seems like unhelpful weasel-wording. I wonder if we ought to have separate messages for each possibility, like "delete tuple (X,Y)" when called from heap_delete(), "update tuple (X,Y)", "check exclusion constraint on tuple (X,Y)" when called from check_exclusion_constraint, etc. That seems like it would be handy information to have. Why can't check_exclusion_constraint, for example, pass the TID, so that at least that much information is available? I'm not very happy with the idea of including the tuple details only when the level is less than ERROR. For one thing, to do that in a way that respects translatability guidelines will require two versions of every string that would otherwise require only one. For another thing, it seems like it's punting a pretty important case. If we're gonna add context detail to lots of cases (instead only the "still waiting" case that people probably mostly care about) then we should actually print the details more-or-less consistently in all of those cases, not pretend like a solution that only works in the narrow case is more general than it really is. I think we should really try hard to make the amount of detail provided as uniform as possible across all the cases, even if that means removing information from some cases where it might have been available. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers