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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Christian Kruse <christian(at)2ndquadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(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-17 22:08:19
Message-ID: 20140317220818.GP6899@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Here's an adjusted version. In this one, the extra info is not used to
construct a string from pieces, but instead it puts it at the end, like
this:

LOG: process 18899 still waiting for ShareLock on transaction 697 after 1000.203 ms
CONTEXT: while operating on tuple (0,2) in relation "public"."foo" of database "postgres": updating tuple

This way, each part can sensibly be translated. In fact I did translate
one instance to test it at work, and it looks good to me:

LOG: el proceso 22555 adquirió ShareLock en transacción 705 después de 1514.017 ms
CONTEXT: mientras se operaba en la tupla (0,2) en la relación "public"."foo" de la base de datos «postgres»: actualizando tupla

Now there might be bikeshedding on the exact wording I've chosen for
each instance of context setup, but I expect it's a fairly minor point
now.

One remaining issue is that now ConditionalXactLockTableWait doesn't set
up error context info. We could solve this by having a common routine
that serves both that one and XactLockTableWait (much like
Do_MultiXactIdWait does), but I'm not sure it's worth the trouble.
Thoughts?

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.

Opinions on these points please? I intend to push this patch tomorrow.

Note: the changes to backend/po/es.po are illustrative only. Those are
not going in with the patch.

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

Attachment Content-Type Size
show_table_name_and_tuple_in_lock_log_v11.patch text/x-diff 18.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-03-17 22:09:21 Re: Planner hints in Postgresql
Previous Message Claudio Freire 2014-03-17 22:07:31 Re: Planner hints in Postgresql