On Tue, Mar 11, 2014 at 3:53 AM, Amit Kapila <amit.kapila16@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
eachvariant.
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
