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

On Thu, Mar 13, 2014 at 7:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Mar 13, 2014 at 12:45 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> _bt_doinsert - "insert index tuple (X,Y)" (here it will refer to index tuple
>> location)
>
> I don't think that giving the index tuple location is going to be very
> helpful; can we get the TID for conflicting heap tuple?

Yes, each index tuple contains reference to TID of heap tuple.

>> IndexBuildHeapScan - "scan tuple (X,Y)"
>> EvalPlanQualFetch - "fetch tuple (X,Y)"
>
> These two seem unhelpful to me. For EvalPlanQualFetch maybe "recheck
> updated tuple" would be good, and for IndexBuildHeapScan perhaps
> "checking uniqueness of tuple".

For IndexBuildHeapScan, "checking uniqueness of tuple" may not be
always the case, as in case of HEAPTUPLE_DELETE_IN_PROGRESS,
it waits on tuple even for HOT.

>> check_exclusion_constraint - "check exclusion constraint on tuple (X,Y)"
>>
>> I think it might not be a big deal to update the patch to pass such info.
>> Won't it effect the translatability guidelines as we need to have different
>> translation message for each op?
>
> Yes, we'll need a separate message for each.

In that case, can't we think of some generic word to use, because in Log
along with this message, it will print the SQL Statement causing this log
as well, so it might not be completely vague to use some generic word.

>
> Well, it's sounding like we can only display the whole tuple if (1)
> the message level is less than ERROR and (2) the snapshot is an MVCC
> snapshot. That's an annoying and hard-to-document set of limitations.
> But we should be able to display the TID always, so I think we should
> drop the part of the patch that tries to show tuple data and revisit
> that in a future release if need be.

Agreed.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com