Fix showing XID of a spectoken lock in an incorrect field of pg_locks view.
Hi,
I realized that pg_locks view shows the transaction id of a
speculative token lock in the database field:
postgres(1:509389)=# select * from pg_locks where locktype = 'spectoken';
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction | pid
| mode | granted | fastpath | waitstart
-----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+--------+---------------+---------+----------+-----------
spectoken | 741 | | | | |
| 3 | 0 | 0 | 3/5 | 509314 |
ExclusiveLock | t | f |
(1 row)
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)
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Attachments:
v1-0001-Fix-showing-transaction-id-of-a-spectoken-lock-in.patchapplication/octet-stream; name=v1-0001-Fix-showing-transaction-id-of-a-spectoken-lock-in.patchDownload
From 8c1ab4af88ae36b5c6bbce98ab49cb9f3bf3e11f Mon Sep 17 00:00:00 2001
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Wed, 4 Jan 2023 15:40:38 +0900
Subject: [PATCH v1] Fix showing transaction id of a spectoken lock in an
incorrect field of pg_locks view.
---
src/backend/utils/adt/lockfuncs.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/src/backend/utils/adt/lockfuncs.c b/src/backend/utils/adt/lockfuncs.c
index 3cce4bdbc1..ab99924558 100644
--- a/src/backend/utils/adt/lockfuncs.c
+++ b/src/backend/utils/adt/lockfuncs.c
@@ -312,6 +312,18 @@ pg_lock_status(PG_FUNCTION_ARGS)
nulls[8] = true;
nulls[9] = true;
break;
+ case LOCKTAG_SPECULATIVE_TOKEN:
+ values[6] =
+ TransactionIdGetDatum(instance->locktag.locktag_field1);
+ values[8] = ObjectIdGetDatum(instance->locktag.locktag_field2);
+ nulls[1] = true;
+ nulls[2] = true;
+ nulls[3] = true;
+ nulls[4] = true;
+ nulls[5] = true;
+ nulls[7] = true;
+ nulls[9] = true;
+ break;
case LOCKTAG_OBJECT:
case LOCKTAG_USERLOCK:
case LOCKTAG_ADVISORY:
--
2.31.1
On Wed, Jan 4, 2023 at 12:16 PM Masahiko Sawada <sawada.mshk@gmail.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]https://www.postgresql.org/docs/devel/view-pg-locks.html. 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.
On Wed, Jan 4, 2023 at 6:42 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Wed, Jan 4, 2023 at 12:16 PM Masahiko Sawada <sawada.mshk@gmail.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?
Agreed. Attached the updated patch.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
Attachments:
v2-0001-Fix-showing-transaction-id-of-a-spectoken-in-an-i.patchapplication/octet-stream; name=v2-0001-Fix-showing-transaction-id-of-a-spectoken-in-an-i.patchDownload
From a34f357e4d2a8edc1947b5e38bab1e20fad06235 Mon Sep 17 00:00:00 2001
From: Masahiko Sawada <sawada.mshk@gmail.com>
Date: Wed, 4 Jan 2023 15:40:38 +0900
Subject: [PATCH v2] Fix showing transaction id of a spectoken in an incorrect
field of pg_locks view.
A transaction id is now displayed in the transactionid field. A
speculative insertion toke is displayed in the objid field.
---
doc/src/sgml/system-views.sgml | 6 ++++++
src/backend/utils/adt/lockfuncs.c | 12 ++++++++++++
2 files changed, 18 insertions(+)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 143ae5b7bb..c5595032b1 100644
--- a/doc/src/sgml/system-views.sgml
+++ b/doc/src/sgml/system-views.sgml
@@ -1578,6 +1578,12 @@
permanent transaction ID of the current holder of that row lock.
</para>
+ <para>
+ A specualtive insertion lock consists of a transaction ID and a speculative
+ insertion token. The speculative insertion token is displayed in the
+ <structfield>objid</structfield> column.
+ </para>
+
<para>
Advisory locks can be acquired on keys consisting of either a single
<type>bigint</type> value or two integer values.
diff --git a/src/backend/utils/adt/lockfuncs.c b/src/backend/utils/adt/lockfuncs.c
index 3cce4bdbc1..ab99924558 100644
--- a/src/backend/utils/adt/lockfuncs.c
+++ b/src/backend/utils/adt/lockfuncs.c
@@ -312,6 +312,18 @@ pg_lock_status(PG_FUNCTION_ARGS)
nulls[8] = true;
nulls[9] = true;
break;
+ case LOCKTAG_SPECULATIVE_TOKEN:
+ values[6] =
+ TransactionIdGetDatum(instance->locktag.locktag_field1);
+ values[8] = ObjectIdGetDatum(instance->locktag.locktag_field2);
+ nulls[1] = true;
+ nulls[2] = true;
+ nulls[3] = true;
+ nulls[4] = true;
+ nulls[5] = true;
+ nulls[7] = true;
+ nulls[9] = true;
+ break;
case LOCKTAG_OBJECT:
case LOCKTAG_USERLOCK:
case LOCKTAG_ADVISORY:
--
2.31.1
On Thu, Jan 5, 2023 at 11:46 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
Agreed. Attached the updated patch.
Thanks, the patch looks good to me. I think it would be probably good
to backpatch this but it has the potential to break some monitoring
scripts which were using the wrong columns for transaction id and spec
token number. As this is not a very critical issue and is not reported
till now, so it may be better to leave backpatching it. What do you
think?
--
With Regards,
Amit Kapila.
On Fri, Jan 6, 2023 at 9:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jan 5, 2023 at 11:46 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
Agreed. Attached the updated patch.
Thanks, the patch looks good to me. I think it would be probably good
to backpatch this but it has the potential to break some monitoring
scripts which were using the wrong columns for transaction id and spec
token number.
Right.
As this is not a very critical issue and is not reported
till now, so it may be better to leave backpatching it. What do you
think?
Considering the compatibility, I'm inclined to agree not to backpatch
it. If someone complains about the current behavior in back branches
in the future, we can backpatch it.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com