mpfuster · Sep 25, 2026 · Sep 25, 2026
diff --git a/docs/pxf/6x/configuring.md b/docs/pxf/6x/configuring.md
@@ -61,7 +61,7 @@ Set up PXF's runtime configuration across the cluster and start the service, so
 
 ## Creating the PXF extension
 
-Create the `pxf` extension in each database that needs external table access. `pxf cluster register`, run as the last step of [installing PXF](installing.md#installing-on-the-cluster), already placed the extension's control, SQL, and shared library files under `$GPHOME` on every host, so you don't need to repeat it here.
+Create the `pxf` extension in each database that needs external table access. `pxf cluster register`, run as the last step of [installing PXF](installing.md), already placed the extension's control, SQL, and shared library files under `$GPHOME` on every host, so you don't need to repeat it here.
 
 1. Connect to the target database and create the extension:
 

diff --git a/docs/pxf/6x/reference/commands.md b/docs/pxf/6x/reference/commands.md
@@ -20,7 +20,7 @@ pxf cluster prepare
 
 ### pxf cluster register
 
-Installs the PXF extension's control, SQL, and shared library files under `$GPHOME` on every host. Needed because `make install` only places these files under `$GPHOME` on the coordinator. See [Installing on the cluster](../installing.md#installing-on-the-cluster) for usage in context.
+Installs the PXF extension's control, SQL, and shared library files under `$GPHOME` on every host. See [Installing](../installing.md) for usage in context.
 
 ```bash
 pxf cluster register

diff --git a/docs/pxf/6x/release_notes/index.md b/docs/pxf/6x/release_notes/index.md
@@ -8,4 +8,4 @@ The PXF documentation describes the latest version of PXF for WarehousePG, inclu
 
 | Version | Release date |
 |---------|--------------|
-| [6.10.2](6.10_rel_notes.md#pxf-6102) | 26 Feb 2026 |
+| [6.10.2](6.10_rel_notes.md) | 26 Feb 2026 |
diff --git a/docs/whpg/7x/ref_guide/sql_commands/LOCK.md b/docs/whpg/7x/ref_guide/sql_commands/LOCK.md
@@ -46,7 +46,6 @@ If multiple tables are given, tables are locked one-by-one in the order specifie
 lockmode
 The lock mode specifies which locks this lock conflicts with. If no lock mode is specified, then `ACCESS EXCLUSIVE`, the most restrictive mode, is used. Lock modes are as follows:
 
-```
 -   ACCESS SHARE — Conflicts with the `ACCESS EXCLUSIVE` lock mode only. The `SELECT` command acquires a lock of this mode on referenced tables. In general, any query that only reads a table and does not modify it will acquire this lock mode.
 -   ROW SHARE — Conflicts with the `EXCLUSIVE` and `ACCESS EXCLUSIVE` lock modes. The `SELECT FOR SHARE` command automatically acquires a lock of this mode on the target table\(s\) \(in addition to `ACCESS SHARE` locks on any other tables that are referenced but not selected `FOR SHARE`\).
 -   ROW EXCLUSIVE — Conflicts with the `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. The commands `INSERT` and `COPY` automatically acquire this lock mode on the target table \(in addition to `ACCESS SHARE` locks on any other referenced tables\) See [Note](#lock_note).
@@ -56,8 +55,9 @@ The lock mode specifies which locks this lock conflicts with. If no lock mode is
 -   EXCLUSIVE — Conflicts with the `ROW SHARE`, `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode allows only concurrent `ACCESS SHARE` locks, i.e., only reads from the table can proceed in parallel with a transaction holding this lock mode. This lock mode is automatically acquired for `UPDATE`, `SELECT FOR UPDATE`, and `DELETE` in WarehousePG \(which is more restrictive locking than in regular PostgreSQL\). See [Note](#lock_note).
 -   ACCESS EXCLUSIVE — Conflicts with locks of all modes \(`ACCESS SHARE`, `ROW SHARE`, `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE`\). This mode guarantees that the holder is the only transaction accessing the table in any way. Acquired automatically by the `ALTER TABLE`, `DROP TABLE`, `TRUNCATE`, `REINDEX`, `CLUSTER`, and `VACUUM FULL` commands. This is the default lock mode for `LOCK TABLE` statements that do not specify a mode explicitly. This lock is also briefly acquired by `VACUUM` \(without `FULL`\) on append-optimized tables during processing.
 
-> **Note** As the default, WarehousePG acquires an `EXCLUSIVE` lock on tables for `DELETE`, `UPDATE`, and `SELECT FOR UPDATE` operations on heap tables. When the Global Deadlock Detector is enabled, the lock mode for the operations on heap tables is `ROW EXCLUSIVE`. See [Global Deadlock Detector](../../admin_guide/dml.html#topic_gdd).
-```
+::: info Note
+As the default, WarehousePG acquires an `EXCLUSIVE` lock on tables for `DELETE`, `UPDATE`, and `SELECT FOR UPDATE` operations on heap tables. When the Global Deadlock Detector is enabled, the lock mode for the operations on heap tables is `ROW EXCLUSIVE`. See [Global Deadlock Detector](../../admin_guide/dml.html#topic_gdd).
+:::
 
 NOWAIT
 Specifies that `LOCK TABLE` should not wait for any conflicting locks to be released: if the specified lock(s) cannot be acquired immediately without waiting, the transaction is cancelled.