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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Christian Kruse <christian(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Date: 2014-03-12 18:46:01
Message-ID: CA+TgmoanQi+Woe2gWsHyGXHK5kv+TT4kXK9iFLgbqiSLZauxTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 11, 2014 at 3:53 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2014-03-12 18:57:33 Re: jsonb and nested hstore
Previous Message Atri Sharma 2014-03-12 18:45:08 Re: GSoC 2014