Re: Patch: show relation and tuple infos of a lock to acquire - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Patch: show relation and tuple infos of a lock to acquire
Date
Msg-id 20140317220818.GP6899@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: Patch: show relation and tuple infos of a lock to acquire  (Christian Kruse <christian@2ndquadrant.com>)
Responses Re: Patch: show relation and tuple infos of a lock to acquire
Re: Patch: show relation and tuple infos of a lock to acquire
List 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»:
actualizandotupla 

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

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pg_dump without explicit table locking
Next
From: Andres Freund
Date:
Subject: Re: First-draft release notes for next week's releases