pg_locks Fails With "Tablet hidden" Error

Environment

• YugabyteDB (YSQL)

Issue

Querying pg_locks or calling yb_lock_status(NULL, NULL) fails with an error like:

ERROR: GetLocations for tablet 63d4fb94f28348ca832476c7e5ff46a9 failed: : Tablet 63d4fb94f28348ca832476c7e5ff46a9 hidden

This occurs when a transaction held locks on a table and the table was subsequently dropped while the lock metadata still referenced the table's tablets. The dropped table's tablets enter a "hidden" state (rather than being immediately deleted), which commonly happens when Point-in-Time Recovery (PITR) is enabled on the database. When pg_locks tries to resolve the location of these hidden tablets, it fails because the code path only handles split-tablet scenarios, not hidden tablets.

Additional Information:
This is a known issue tracked in GHI #23084.

Resolution

Overview

The hidden tablet reference must be cleared from the TServer's in-memory state. The only current workaround is to restart the affected TServer(s).

Steps

1. Identify the affected TServer.

The error message contains the tablet UUID. The affected TServer is the one serving as the leader for that tablet. Look up the leader from the Master UI on tables page.

https://<master-ip>:7000/table?id=<table-id>

2. Restart the affected TServer.

Restarting the TServer clears the stale in-memory lock state that references the hidden tablet:

# For YugabyteDB Anywhere managed clusters:
systemctl --user restart yb-tserver

# For manual deployments:
yugabyted stop --base_dir=<base_dir>
yugabyted start --base_dir=<base_dir>

3. Verify the fix.

After the TServer restarts and rejoins the cluster, confirm that pg_locks works again:

SELECT * FROM pg_locks LIMIT 1;

Or:

SELECT * FROM yb_lock_status(NULL, NULL) LIMIT 1;

The query should return results (or an empty set) without error.

Additional Information:

• This issue is more likely to occur when PITR is enabled, because dropped table tablets are hidden rather than immediately deleted.
• The error is transient in nature — it only persists as long as the TServer holds stale references to the hidden tablet in memory.
• Normal lock operations (SELECT ... FOR UPDATE, row-level locking, etc.) are not affected by this issue — only the pg_locks and yb_lock_status() diagnostic views fail.
• This issue is tracked in GHI #23084

Internal Reference Number: SUPPORT-896