Re: Fix showing XID of a spectoken lock in an incorrect field of pg_locks view.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix showing XID of a spectoken lock in an incorrect field of pg_locks view.
Date: 2023-01-04 09:42:37
Message-ID: CAA4eK1LaHo_85uHRtAscYNTbw6ZjZFy0tFdD7tCzXVEtxDnUwQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 4, 2023 at 12:16 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> It seems to be confusing and the user won't get the result even if
> they search it by transactionid = 741. So I've attached the patch to
> fix it. With the patch, the pg_locks views shows like:
>
> locktype | database | relation | page | tuple | virtualxid |
> transactionid | classid | objid | objsubid | virtualtransaction | pid
> | mode | granted | fastpath | waitstart
> -----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+--------+---------------+---------+----------+-----------
> spectoken | | | | | |
> 746 | | 1 | | 3/4 | 535618 |
> ExclusiveLock | t | f |
> (1 row)
>

Is it a good idea to display spec token as objid, if so, how will
users know? Currently for Advisory locks, we display values in
classid, objid, objsubid different than the original meaning of fields
but those are explained in docs [1]. Wouldn't it be better to mention
this in docs?

[1] - https://www.postgresql.org/docs/devel/view-pg-locks.html

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-01-04 09:49:24 Re: Parallelize correlated subqueries that execute within each worker
Previous Message vignesh C 2023-01-04 09:40:48 Re: POC: Lock updated tuples in tuple_update() and tuple_delete()