From 37bc682339a7da8ba153756596b0d82e15b263d8 Mon Sep 17 00:00:00 2001 From: Josh Heyer Date: Fri, 25 Sep 2026 15:28:11 -0700 Subject: [PATCH 1/2] Clean up formatting in LOCK reference topics (#119) --- docs/whpg/6x/ref_guide/sql_commands/LOCK.md | 88 +++++++-------------- docs/whpg/7x/ref_guide/sql_commands/LOCK.md | 72 ++++++++--------- 2 files changed, 62 insertions(+), 98 deletions(-) diff --git a/docs/whpg/6x/ref_guide/sql_commands/LOCK.md b/docs/whpg/6x/ref_guide/sql_commands/LOCK.md index 903b45b6..fa2e8fef 100644 --- a/docs/whpg/6x/ref_guide/sql_commands/LOCK.md +++ b/docs/whpg/6x/ref_guide/sql_commands/LOCK.md @@ -1,20 +1,11 @@ --- title: LOCK - --- - - Locks a table. - - - - ## Synopsis - - ``` LOCK [TABLE] [ONLY] name [ * ] [, ...] [IN MODE] [NOWAIT] [MASTER ONLY] ``` @@ -22,14 +13,10 @@ LOCK [TABLE] [ONLY] name [ * ] [, ...] [IN MODE] [NOWAIT] [MASTER ONL where lockmode is one of: ``` - ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE - | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE +ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE +| SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE ``` - - - - ## Description `LOCK TABLE` obtains a table-level lock, waiting if necessary for any conflicting locks to be released. If `NOWAIT` is specified, `LOCK TABLE` does not wait to acquire the desired lock: if it cannot be acquired immediately, the command is stopped and an error is emitted. Once obtained, the lock is held for the remainder of the current transaction. There is no `UNLOCK TABLE` command; locks are always released at transaction end. @@ -40,55 +27,48 @@ To achieve a similar effect when running a transaction at the `REPEATABLE READ` If a transaction of this sort is going to change the data in the table, then it should use `SHARE ROW EXCLUSIVE` lock mode instead of `SHARE` mode. This ensures that only one transaction of this type runs at a time. Without this, a deadlock is possible: two transactions might both acquire `SHARE` mode, and then be unable to also acquire `ROW EXCLUSIVE` mode to actually perform their updates. Note that a transaction's own locks never conflict, so a transaction can acquire `ROW EXCLUSIVE` mode when it holds `SHARE` mode — but not if anyone else holds `SHARE` mode. To avoid deadlocks, make sure all transactions acquire locks on the same objects in the same order, and if multiple lock modes are involved for a single object, then transactions should always acquire the most restrictive mode first. - - - - ## Parameters -- name +- name - The name (optionally schema-qualified) of an existing table to lock. If `ONLY` is specified, only that table is locked. If `ONLY` is not specified, the table and all its descendant tables (if any) are locked. Optionally, `*` can be specified after the table name to explicitly indicate that descendant tables are included. + The name (optionally schema-qualified) of an existing table to lock. If `ONLY` is specified, only that table is locked. If `ONLY` is not specified, the table and all its descendant tables (if any) are locked. Optionally, `*` can be specified after the table name to explicitly indicate that descendant tables are included. - If multiple tables are given, tables are locked one-by-one in the order specified in the `LOCK TABLE` command. + If multiple tables are given, tables are locked one-by-one in the order specified in the `LOCK TABLE` command. -- lockmode +- 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: + 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). - - - SHARE UPDATE EXCLUSIVE — Conflicts with the `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent schema changes and `VACUUM` runs. Acquired by `VACUUM` (without `FULL`) on heap tables and `ANALYZE`. - - - SHARE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE ROW EXCLUSIVE, EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent data changes. Acquired automatically by `CREATE INDEX`. - - - SHARE ROW EXCLUSIVE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This lock mode is not automatically acquired by any WarehousePG command. - - - 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. + - 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). + - SHARE UPDATE EXCLUSIVE — Conflicts with the `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent schema changes and `VACUUM` runs. Acquired by `VACUUM` (without `FULL`) on heap tables and `ANALYZE`. + - SHARE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE ROW EXCLUSIVE, EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent data changes. Acquired automatically by `CREATE INDEX`. + - SHARE ROW EXCLUSIVE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This lock mode is not automatically acquired by any WarehousePG command. + - 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** By default WarehousePG acquires the more restrictive `EXCLUSIVE` lock (rather than `ROW EXCLUSIVE` in PostgreSQL) for `UPDATE`, `DELETE`, and `SELECT...FOR UPDATE` operations on heap tables. When the Global Deadlock Detector is enabled the lock mode for `UPDATE` and `DELETE` operations on heap tables is `ROW EXCLUSIVE`. See [Global Deadlock Detector](../../admin_guide/dml.md#topic_gdd). WarehousePG always holds a table-level lock with `SELECT...FOR UPDATE` statements. + ::: Note -- NOWAIT + + + By default WarehousePG acquires the more restrictive `EXCLUSIVE` lock (rather than `ROW EXCLUSIVE` in PostgreSQL) for `UPDATE`, `DELETE`, and `SELECT...FOR UPDATE` operations on heap tables. When the Global Deadlock Detector is enabled the lock mode for `UPDATE` and `DELETE` operations on heap tables is `ROW EXCLUSIVE`. See [Global Deadlock Detector](../../admin_guide/dml.md#topic_gdd). WarehousePG always holds a table-level lock with `SELECT...FOR UPDATE` statements. - 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. + ::: -- MASTER ONLY +- NOWAIT - Specifies that when a `LOCK TABLE` command is issued, WarehousePG will lock tables on the coordinator only, rather than on the coordinator and all of the segments. This is particularly useful for metadata-only operations. + 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. - > **Note** This option is only supported in `ACCESS SHARE MODE`. +- MASTER ONLY - + Specifies that when a `LOCK TABLE` command is issued, WarehousePG will lock tables on the coordinator only, rather than on the coordinator and all of the segments. This is particularly useful for metadata-only operations. - + ::: Note + + This option is only supported in `ACCESS SHARE MODE`. - + ::: ## Notes @@ -98,10 +78,6 @@ If a transaction of this sort is going to change the data in the table, then it `LOCK TABLE` only deals with table-level locks, and so the mode names involving `ROW` are all misnomers. These mode names should generally be read as indicating the intention of the user to acquire row-level locks within the locked table. Also, `ROW EXCLUSIVE` mode is a shareable table lock. Keep in mind that all the lock modes have identical semantics so far as `LOCK TABLE` is concerned, differing only in the rules about which modes conflict with which. For information on how to acquire an actual row-level lock, see the `FOR UPDATE/FOR SHARE` clause in the [SELECT](SELECT.md) reference documentation. - - - - ## Examples Obtain a `SHARE` lock on the `films` table when going to perform inserts into the `films_user_comments` table: @@ -128,20 +104,12 @@ DELETE FROM films WHERE rating < 5; COMMIT WORK; ``` - - - - ## Compatibility There is no `LOCK TABLE` in the SQL standard, which instead uses `SET TRANSACTION` to specify concurrency levels on transactions. WarehousePG supports that too. Except for `ACCESS SHARE`, `ACCESS EXCLUSIVE`, and `SHARE UPDATE EXCLUSIVE` lock modes, the WarehousePG lock modes and the `LOCK TABLE` syntax are compatible with those present in Oracle. - - - - ## See Also [BEGIN](BEGIN.md), [SET TRANSACTION](SET_TRANSACTION.md), [SELECT](SELECT.md) diff --git a/docs/whpg/7x/ref_guide/sql_commands/LOCK.md b/docs/whpg/7x/ref_guide/sql_commands/LOCK.md index f47f2cd2..8bb9c4ca 100644 --- a/docs/whpg/7x/ref_guide/sql_commands/LOCK.md +++ b/docs/whpg/7x/ref_guide/sql_commands/LOCK.md @@ -1,16 +1,11 @@ --- title: LOCK - --- Locks a table. - - ## Synopsis -
- ``` LOCK [TABLE] [ONLY] name [ * ] [, ...] [IN MODE] [NOWAIT] [COORDINATOR ONLY] ``` @@ -18,12 +13,10 @@ LOCK [TABLE] [ONLY] name [ * ] [, ...] [IN MODE] [NOWAIT] [COORDINATO where lockmode is one of: ``` - ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE - | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE +ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE +| SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE ``` - - ## Description `LOCK TABLE` obtains a table-level lock, waiting if necessary for any conflicting locks to be released. If `NOWAIT` is specified, `LOCK TABLE` does not wait to acquire the desired lock: if it cannot be acquired immediately, the command is stopped and an error is emitted. Once obtained, the lock is held for the remainder of the current transaction. There is no `UNLOCK TABLE` command; locks are always released at transaction end. @@ -34,42 +27,51 @@ To achieve a similar effect when running a transaction at the `REPEATABLE READ` If a transaction of this sort is going to change the data in the table, then it should use `SHARE ROW EXCLUSIVE` lock mode instead of `SHARE` mode. This ensures that only one transaction of this type runs at a time. Without this, a deadlock is possible: two transactions might both acquire `SHARE` mode, and then be unable to also acquire `ROW EXCLUSIVE` mode to actually perform their updates. Note that a transaction's own locks never conflict, so a transaction can acquire `ROW EXCLUSIVE` mode when it holds `SHARE` mode — but not if anyone else holds `SHARE` mode. To avoid deadlocks, make sure all transactions acquire locks on the same objects in the same order, and if multiple lock modes are involved for a single object, then transactions should always acquire the most restrictive mode first. - - ## Parameters -name +### name + The name (optionally schema-qualified) of an existing table to lock. If `ONLY` is specified, only that table is locked. If `ONLY` is not specified, the table and all its descendant tables (if any) are locked. Optionally, `*` can be specified after the table name to explicitly indicate that descendant tables are included. If multiple tables are given, tables are locked one-by-one in the order specified in the `LOCK TABLE` command. -lockmode +### 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). -- SHARE UPDATE EXCLUSIVE — Conflicts with the `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent schema changes and `VACUUM` runs. Acquired by `VACUUM` \(without `FULL`\) on heap tables and `ANALYZE`. -- SHARE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE ROW EXCLUSIVE, EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent data changes. Acquired automatically by `CREATE INDEX`. -- SHARE ROW EXCLUSIVE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent data changes, and is self-exclusive so that only one session can hold it at a time. This lock mode is not automatically acquired by any WarehousePG command. -- 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. +- 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. -::: 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). -::: +- 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`\). -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. +- 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). -COORDINATOR ONLY -Specifies that when a `LOCK TABLE` command is issued, WarehousePG will lock tables on the coordinator only, rather than on the coordinator and all of the segments. This is particularly useful for metadata-only operations. +- SHARE UPDATE EXCLUSIVE — Conflicts with the `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent schema changes and `VACUUM` runs. Acquired by `VACUUM` \(without `FULL`\) on heap tables and `ANALYZE`. -``` -

> **Note** This option is only supported in `ACCESS SHARE MODE`. -``` +- SHARE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE ROW EXCLUSIVE, EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent data changes. Acquired automatically by `CREATE INDEX`. + +- SHARE ROW EXCLUSIVE — Conflicts with the `ROW EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE`, `SHARE`, `SHARE ROW EXCLUSIVE`, `EXCLUSIVE`, and `ACCESS EXCLUSIVE` lock modes. This mode protects a table against concurrent data changes, and is self-exclusive so that only one session can hold it at a time. This lock mode is not automatically acquired by any WarehousePG command. + +- 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. + + ::: 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. + +- COORDINATOR ONLY + Specifies that when a `LOCK TABLE` command is issued, WarehousePG will lock tables on the coordinator only, rather than on the coordinator and all of the segments. This is particularly useful for metadata-only operations. + + :::Note This option is only supported in `ACCESS SHARE MODE`. + + ::: ## Notes @@ -79,8 +81,6 @@ Specifies that when a `LOCK TABLE` command is issued, WarehousePG will lock tabl `LOCK TABLE` only deals with table-level locks, and so the mode names involving `ROW` are all misnomers. These mode names should generally be read as indicating the intention of the user to acquire row-level locks within the locked table. Also, `ROW EXCLUSIVE` mode is a shareable table lock. Keep in mind that all the lock modes have identical semantics so far as `LOCK TABLE` is concerned, differing only in the rules about which modes conflict with which. For information on how to acquire an actual row-level lock, see the `FOR UPDATE/FOR SHARE` clause in the [SELECT](SELECT.md) reference documentation. - - ## Examples Obtain a `SHARE` lock on the `films` table when going to perform inserts into the `films_user_comments` table: @@ -107,16 +107,12 @@ DELETE FROM films WHERE rating < 5; COMMIT WORK; ``` - - ## Compatibility There is no `LOCK TABLE` in the SQL standard, which instead uses `SET TRANSACTION` to specify concurrency levels on transactions. WarehousePG supports that too; see [SET TRANSACTION](SET_TRANSACTION.md) for details. Except for `ACCESS SHARE`, `ACCESS EXCLUSIVE`, and `SHARE UPDATE EXCLUSIVE` lock modes, the WarehousePG lock modes and the `LOCK TABLE` syntax are compatible with those present in Oracle. - - ## See Also [BEGIN](BEGIN.md), [SET TRANSACTION](SET_TRANSACTION.md), [SELECT](SELECT.md) From 6b9f1b1b7d9996a6e4a2f4a84b53f12b2ec88108 Mon Sep 17 00:00:00 2001 From: Mireia Perez Date: Wed, 30 Sep 2026 11:43:33 +0100 Subject: [PATCH 2/2] Find old mentions to Postgres 9.4 in WHPG 7 docs --- docs/extensions/bundled/dblink.md | 4 ++-- docs/extensions/bundled/gp_array_agg.md | 2 +- docs/extensions/bundled/gp_percentile_agg.md | 2 +- docs/extensions/bundled/greenplum_fdw.md | 8 +++---- docs/extensions/bundled/isn.md | 2 +- .../client_auth/kerberos-win-client.md | 4 ++-- .../manage_access/client_auth/kerberos.md | 2 +- .../7x/ref_guide/config_params/guc-list.md | 4 ++-- .../whpg/7x/ref_guide/misc/feature_summary.md | 24 +++++++++---------- docs/whpg/7x/ref_guide/misc/sql-keywords.md | 4 ++-- .../utility_guide/reference/pg_restore.md | 4 ++-- docs/whpg/7x/security_guide/index.md | 2 +- 12 files changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/extensions/bundled/dblink.md b/docs/extensions/bundled/dblink.md index 5499b05f..abee6005 100644 --- a/docs/extensions/bundled/dblink.md +++ b/docs/extensions/bundled/dblink.md @@ -50,7 +50,7 @@ The following procedure identifies the basic steps for configuring and using `db ``` $ psql -d postgres - psql (9.4.20) + psql (12.12) Type "help" for help. postgres=# CREATE TABLE testdblink (a int, b text) DISTRIBUTED BY (a); @@ -65,7 +65,7 @@ The following procedure identifies the basic steps for configuring and using `db ``` $ psql -d testdb - psql (9.4beta1) + psql (12.12) Type "help" for help. testdb=# CREATE EXTENSION dblink; diff --git a/docs/extensions/bundled/gp_array_agg.md b/docs/extensions/bundled/gp_array_agg.md index 35936e00..db3c5073 100644 --- a/docs/extensions/bundled/gp_array_agg.md +++ b/docs/extensions/bundled/gp_array_agg.md @@ -67,4 +67,4 @@ SELECT gp_array_agg(a ORDER BY b NULLS FIRST) FROM table1; ## Additional Module Documentation -Refer to [Aggregate Functions](https://www.postgresql.org/docs/9.4/functions-aggregate.html) in the PostgreSQL documentation for more information about aggregates. +Refer to [Aggregate Functions](https://www.postgresql.org/docs/12/functions-aggregate.html) in the PostgreSQL documentation for more information about aggregates. diff --git a/docs/extensions/bundled/gp_percentile_agg.md b/docs/extensions/bundled/gp_percentile_agg.md index b0aedf08..81e68b15 100644 --- a/docs/extensions/bundled/gp_percentile_agg.md +++ b/docs/extensions/bundled/gp_percentile_agg.md @@ -56,4 +56,4 @@ When the extension is registered, `optimizer_enable_orderedagg` is enabled, and ## Additional Module Documentation -Refer to [Ordered-Set Aggregate Functions](https://www.postgresql.org/docs/9.4/functions-aggregate.html#FUNCTIONS-ORDEREDSET-TABLE) in the PostgreSQL documentation for more information about using ordered-set aggregates. +Refer to [Ordered-Set Aggregate Functions](https://www.postgresql.org/docs/12/functions-aggregate.html#FUNCTIONS-ORDEREDSET-TABLE) in the PostgreSQL documentation for more information about using ordered-set aggregates. diff --git a/docs/extensions/bundled/greenplum_fdw.md b/docs/extensions/bundled/greenplum_fdw.md index 16b9a62f..bf60315e 100644 --- a/docs/extensions/bundled/greenplum_fdw.md +++ b/docs/extensions/bundled/greenplum_fdw.md @@ -52,7 +52,7 @@ Refer to [Installing Extensions](/docs/6x/install_guide/additional_modules/index ## About the greenplum_fdw Module -`greenplum_fdw` is an MPP version of the [postgres_fdw](https://www.postgresql.org/docs/9.4/postgres-fdw.html) foreign-data wrapper. While it behaves similarly to `postgres_fdw` in many respects, `greenplum_fdw` uses a WarehousePG parallel retrieve cursor to pull data directly from the segments of a remote WarehousePG cluster to the segments in the local WarehousePG cluster, in parallel. +`greenplum_fdw` is an MPP version of the [postgres_fdw](https://www.postgresql.org/docs/12/postgres-fdw.html) foreign-data wrapper. While it behaves similarly to `postgres_fdw` in many respects, `greenplum_fdw` uses a WarehousePG parallel retrieve cursor to pull data directly from the segments of a remote WarehousePG cluster to the segments in the local WarehousePG cluster, in parallel. By supporting predicate pushdown, `greenplum_fdw` minimizes the amount of data transferred between the WarehousePG clusters by sending a query filter condition to the remote WarehousePG server where it is applied there. @@ -77,7 +77,7 @@ You will perform the following tasks when you use `greenplum_fdw` to access data To access a remote WarehousePG cluster, you must first create a foreign server object which specifies the host, port, and database connection details. You provide these connection parameters in the `OPTIONS` clause of the [CREATE SERVER](/docs/6x/ref_guide/sql_commands/CREATE_SERVER.md) command. -A foreign server using the `greenplum_fdw` foreign-data wrapper accepts and disallows the same options as that of a foreign server using the `postgres_fdw` FDW; refer to the [Connection Options](https://www.postgresql.org/docs/9.4/postgres-fdw.html) topic in the PostgreSQL `postgres_fdw` documentation for more information about these options. +A foreign server using the `greenplum_fdw` foreign-data wrapper accepts and disallows the same options as that of a foreign server using the `postgres_fdw` FDW; refer to the [Connection Options](https://www.postgresql.org/docs/12/postgres-fdw.html) topic in the PostgreSQL `postgres_fdw` documentation for more information about these options. To obtain the full benefits of the parallel transfer feature provided by `greenplum_fdw`, you must also specify: @@ -208,7 +208,7 @@ Setting this option at the foreign table-level overrides a foreign server-level ### About the Cost Estimation Options -`greenplum_fdw` supports the same cost estimation options as described in the [Cost Estimation Options](https://www.postgresql.org/docs/9.4/postgres-fdw.html) topic in the PostgreSQL `postgres_fdw` documentation. +`greenplum_fdw` supports the same cost estimation options as described in the [Cost Estimation Options](https://www.postgresql.org/docs/12/postgres-fdw.html) topic in the PostgreSQL `postgres_fdw` documentation. @@ -224,7 +224,7 @@ Setting this option at the foreign table-level overrides a foreign server-level ### About Transaction Management -`greenplum_fdw` manages transactions as described in the [Transaction Management](https://www.postgresql.org/docs/9.4/postgres-fdw.html) topic in the PostgreSQL `postgres_fdw` documentation. +`greenplum_fdw` manages transactions as described in the [Transaction Management](https://www.postgresql.org/docs/12/postgres-fdw.html) topic in the PostgreSQL `postgres_fdw` documentation. diff --git a/docs/extensions/bundled/isn.md b/docs/extensions/bundled/isn.md index cdb283de..8273e132 100644 --- a/docs/extensions/bundled/isn.md +++ b/docs/extensions/bundled/isn.md @@ -27,4 +27,4 @@ Refer to [Installing Extensions](/docs/7x/install_guide/additional_modules/index ## Module Documentation -Refer to the [isn Postgres documentation](https://www.postgresql.org/docs/9.4/isn.html) for detailed information about using the module. +Refer to the [isn Postgres documentation](https://www.postgresql.org/docs/12/isn.html) for detailed information about using the module. diff --git a/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos-win-client.md b/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos-win-client.md index ad5c61e1..258dcc67 100644 --- a/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos-win-client.md +++ b/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos-win-client.md @@ -96,7 +96,7 @@ If you get warnings indicating that the Console code page differs from Windows c ``` psql -h prod1.example.local warehouse -psql (9.4.20) +psql (12.12) WARNING: Console code page (850) differs from Windows code page (1252) 8-bit characters might not work correctly. See psql reference page "Notes for Windows users" for details. @@ -108,7 +108,7 @@ chcp 1252 Active code page: 1252 psql -h prod1.example.local warehouse -psql (9.4.20) +psql (12.12) Type "help" for help. ``` diff --git a/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos.md b/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos.md index 6716ef98..5435810e 100644 --- a/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos.md +++ b/docs/whpg/7x/admin_guide/manage_access/client_auth/kerberos.md @@ -168,7 +168,7 @@ Configure WarehousePG to use Kerberos. ``` $ psql -U "gpadmin/admin" -h cdw postgres - psql (9.4.20) + psql (12.12) Type "help" for help. postgres=# select current_user; diff --git a/docs/whpg/7x/ref_guide/config_params/guc-list.md b/docs/whpg/7x/ref_guide/config_params/guc-list.md index b4d28828..88ce8f9d 100644 --- a/docs/whpg/7x/ref_guide/config_params/guc-list.md +++ b/docs/whpg/7x/ref_guide/config_params/guc-list.md @@ -2195,7 +2195,7 @@ Sets the display format for interval values. The value *sql_standard* produces o The value *postgres_verbose* produces output matching WarehousePG releases prior to 3.3 when the [DateStyle](#datestyle) parameter was set to non-ISO output. -The value *iso_8601* will produce output matching the time interval *format with designators* defined in section 4.4.3.2 of ISO 8601. See the [PostgreSQL 9.4 documentation](https://www.postgresql.org/docs/12/datatype-datetime.html) for more information. +The value *iso_8601* will produce output matching the time interval *format with designators* defined in section 4.4.3.2 of ISO 8601. See the [PostgreSQL 12 documentation](https://www.postgresql.org/docs/12/datatype-datetime.html) for more information. | Value Range | Default | Set Classifications | | -------------------------------------------------- | -------- | ---------------------------- | @@ -3738,7 +3738,7 @@ Reports the version of PostgreSQL that this release of WarehousePG is based on. | Value Range | Default | Set Classifications | | ----------- | ------- | ------------------- | -| string | 9.4.20 | read only | +| string | 12.12 | read only | diff --git a/docs/whpg/7x/ref_guide/misc/feature_summary.md b/docs/whpg/7x/ref_guide/misc/feature_summary.md index ba49f7cf..6046223d 100644 --- a/docs/whpg/7x/ref_guide/misc/feature_summary.md +++ b/docs/whpg/7x/ref_guide/misc/feature_summary.md @@ -127,7 +127,7 @@ The following features of SQL 2008 are not supported in WarehousePG: ## WarehousePG and PostgreSQL Compatibility -WarehousePG is based on PostgreSQL 9.4. To support the distributed nature and typical workload of a WarehousePG cluster, some SQL commands have been added or modified, and there are a few PostgreSQL features that are not supported. WarehousePG has also added features not found in PostgreSQL, such as physical data distribution, parallel query optimization, external tables, resource queues, and enhanced table partitioning. For full SQL syntax and references, see the [SQL Commands](../sql_commands/index.md). +WarehousePG is based on PostgreSQL 12.12. To support the distributed nature and typical workload of a WarehousePG cluster, some SQL commands have been added or modified, and there are a few PostgreSQL features that are not supported. WarehousePG has also added features not found in PostgreSQL, such as physical data distribution, parallel query optimization, external tables, resource queues, and enhanced table partitioning. For full SQL syntax and references, see the [SQL Commands](../sql_commands/index.md). > **Note** WarehousePG does not support the PostgreSQL [large object facility](https://www.postgresql.org/docs/12/largeobjects.html) for streaming user data that is stored in large-object structures. @@ -144,7 +144,7 @@ WarehousePG is based on PostgreSQL 9.4. To support the distributed nature and ty | `ALTER DATABASE` | YES | | | `ALTER DOMAIN` | YES | | | `ALTER EVENT TRIGGER` | YES | | -| `ALTER EXTENSION` | YES | Changes the definition of a WarehousePG extension - based on PostgreSQL 9.6. | +| `ALTER EXTENSION` | YES | Changes the definition of a WarehousePG extension - based on PostgreSQL. | | `ALTER FUNCTION` | YES | | | `ALTER GROUP` | YES | An alias for [ALTER ROLE](../sql_commands/ALTER_ROLE.md) | | `ALTER INDEX` | YES | | @@ -182,19 +182,19 @@ WarehousePG is based on PostgreSQL 9.4. To support the distributed nature and ty | `CREATE DATABASE` | YES | | | `CREATE DOMAIN` | YES | | | `CREATE EVENT TRIGGER` | YES | | -| `CREATE EXTENSION` | YES | Loads a new extension into WarehousePG - based on PostgreSQL 9.6. | -| `CREATE EXTERNAL TABLE` | YES | WarehousePG parallel ETL feature - not in PostgreSQL 9.4. | +| `CREATE EXTENSION` | YES | Loads a new extension into WarehousePG - based on PostgreSQL. | +| `CREATE EXTERNAL TABLE` | YES | WarehousePG parallel ETL feature - not in PostgreSQL. | | `CREATE FUNCTION` | YES | **Limitations:**

Functions defined as `STABLE` or `VOLATILE` can be run in WarehousePG provided that they are run on the coordinator only. `STABLE` and `VOLATILE` functions cannot be used in statements that run at the segment level. | | `CREATE GROUP` | YES | An alias for [CREATE ROLE](../sql_commands/CREATE_ROLE.md) | | `CREATE INDEX` | YES | **WarehousePG Clauses:**

`USING bitmap` (bitmap indexes)

**Limitations:**

`UNIQUE` indexes are allowed only if they contain all of (or a superset of) the WarehousePG distribution key columns. On partitioned tables, a unique index is only supported within an individual partition - not across all partitions.

`CONCURRENTLY` keyword not supported in WarehousePG. | | `CREATE LANGUAGE` | YES | | -| `CREATE MATERIALIZED VIEW` | YES | Based on PostgreSQL 9.4. | +| `CREATE MATERIALIZED VIEW` | YES | Based on PostgreSQL 12.12. | | `CREATE OPERATOR` | YES | **Limitations:**

The function used to implement the operator must be an `IMMUTABLE` function. | | `CREATE OPERATOR CLASS` | YES | | | `CREATE OPERATOR FAMILY` | YES | | | `CREATE PROTOCOL` | YES | | | `CREATE PUBLICATION` | NO | | -| `CREATE RESOURCE QUEUE` | YES | WarehousePG resource management feature - not in PostgreSQL 9.4. | +| `CREATE RESOURCE QUEUE` | YES | WarehousePG resource management feature - not in PostgreSQL. | | `CREATE ROLE` | YES | **WarehousePG Clauses:**

`RESOURCE QUEUE`*queue_name*` \| none` | | `CREATE RULE` | YES | | | `CREATE SCHEMA` | YES | | @@ -211,15 +211,15 @@ WarehousePG is based on PostgreSQL 9.4. To support the distributed nature and ty | `DECLARE` | YES | **Unsupported Clauses / Options:**

`SCROLL`

`FOR UPDATE [ OF column [, ...] ]`

**Limitations:**

Cursors cannot be backward-scrolled. Forward scrolling is supported.

PL/pgSQL does not have support for updatable cursors. | | `DELETE` | YES | | | `DISCARD` | YES | **Limitation:** `DISCARD ALL` is not supported. | -| `DO` | YES | PostgreSQL 9.0 feature | +| `DO` | YES | PostgreSQL feature | | `DROP AGGREGATE` | YES | | | `DROP CAST` | YES | | | `DROP CONVERSION` | YES | | | `DROP DATABASE` | YES | | | `DROP DOMAIN` | YES | | | `DROP EVENT TRIGGER` | YES | | -| `DROP EXTENSION` | YES | Removes an extension from WarehousePG – based on PostgreSQL 9.6. | -| `DROP EXTERNAL TABLE` | YES | WarehousePG parallel ETL feature - not in PostgreSQL 9.4. | +| `DROP EXTENSION` | YES | Removes an extension from WarehousePG – based on PostgreSQL. | +| `DROP EXTERNAL TABLE` | YES | WarehousePG parallel ETL feature - not in PostgreSQL. | | `DROP FUNCTION` | YES | | | `DROP GROUP` | YES | An alias for [DROP ROLE](../sql_commands/DROP_ROLE.md) | | `DROP INDEX` | YES | | @@ -230,7 +230,7 @@ WarehousePG is based on PostgreSQL 9.4. To support the distributed nature and ty | `DROP OWNED` | **NO** | | | `DROP PROTOCOL` | YES | | | `DROP PUBLICATION` | NO | | -| `DROP RESOURCE QUEUE` | YES | WarehousePG resource management feature - not in PostgreSQL 9.4. | +| `DROP RESOURCE QUEUE` | YES | WarehousePG resource management feature - not in PostgreSQL 12.12. | | `DROP ROLE` | YES | | | `DROP RULE` | YES | | | `DROP SCHEMA` | YES | | @@ -257,11 +257,11 @@ WarehousePG is based on PostgreSQL 9.4. To support the distributed nature and ty | `PREPARE` | YES | | | `PREPARE TRANSACTION` | **NO** | | | `REASSIGN OWNED` | YES | | -| `REFRESH MATERIALIZED VIEW` | YES | Based on PostgreSQL 9.4. | +| `REFRESH MATERIALIZED VIEW` | YES | Based on PostgreSQL. | | `REINDEX` | YES | | | `RELEASE SAVEPOINT` | YES | | | `RESET` | YES | | -| `RETRIEVE` | YES | WarehousePG parallel retrieve cursor - not in PostgreSQL 9.4. | +| `RETRIEVE` | YES | WarehousePG parallel retrieve cursor - not in PostgreSQL. | | `REVOKE` | YES | | | `ROLLBACK` | YES | | | `ROLLBACK PREPARED` | **NO** | | diff --git a/docs/whpg/7x/ref_guide/misc/sql-keywords.md b/docs/whpg/7x/ref_guide/misc/sql-keywords.md index e2742420..5dca8965 100644 --- a/docs/whpg/7x/ref_guide/misc/sql-keywords.md +++ b/docs/whpg/7x/ref_guide/misc/sql-keywords.md @@ -25,7 +25,7 @@ See [SQL Syntax](https://www.postgresql.org/docs/12/sql-syntax.html) in the Post ## SQL Key Words -[SQL keyword status](#sql-keyword-status) lists all tokens that are key words in WarehousePG 6 and PostgreSQL 9.4. +[SQL keyword status](#sql-keyword-status) lists all tokens that are key words in WarehousePG and PostgreSQL. ANSI SQL distinguishes between *reserved* and *unreserved* key words. According to the standard, reserved key words are the only real key words; they are never allowed as identifiers. Unreserved key words only have a special meaning in particular contexts and can be used as identifiers in other contexts. Most unreserved key words are actually the names of built-in tables and functions specified by SQL. The concept of unreserved key words essentially only exists to declare that some predefined meaning is attached to a word in some contexts. @@ -39,7 +39,7 @@ Before studying the table, note the fact that a key word is not reserved does no ### SQL keyword status -| Key Word | WarehousePG | PostgreSQL 9.4 | +| Key Word | WarehousePG | PostgreSQL 12.12 | | :------------------ | :------------------------------------------- | :------------------------------------------- | | ABORT | unreserved | unreserved | | ABSOLUTE | unreserved | unreserved | diff --git a/docs/whpg/7x/ref_guide/utility_guide/reference/pg_restore.md b/docs/whpg/7x/ref_guide/utility_guide/reference/pg_restore.md index cd8d65cb..27fa3e50 100644 --- a/docs/whpg/7x/ref_guide/utility_guide/reference/pg_restore.md +++ b/docs/whpg/7x/ref_guide/utility_guide/reference/pg_restore.md @@ -293,8 +293,8 @@ The listing file consists of a header and one line for each item, for example, ; Format: CUSTOM ; Integer: 4 bytes ; Offset: 8 bytes -; Dumped from database version: 9.4.24 -; Dumped by pg_dump version: 9.4.24 +; Dumped from database version: 12.12 +; Dumped by pg_dump version: 12.12 ; ; Selected TOC Entries: ; diff --git a/docs/whpg/7x/security_guide/index.md b/docs/whpg/7x/security_guide/index.md index 769c5f05..3cf35219 100644 --- a/docs/whpg/7x/security_guide/index.md +++ b/docs/whpg/7x/security_guide/index.md @@ -16,7 +16,7 @@ This guide describes how to secure a WarehousePG cluster. The guide assumes know > **Important** Because WarehousePG is based on PostgreSQL, certain commercial security scanning software, when trying to identify WarehousePG vulnerabilities, may use a PostgreSQL database profile. The reports generated by these tools can produce misleading results, and cannot be trusted as an accurate assessment of vulnerabilities that may exist in WarehousePG. -Because WarehousePG is based on PostgreSQL 9.4, this guide assumes some familiarity with PostgreSQL. References to [PostgreSQL documentation](https://www.postgresql.org/docs/12/index.html) are provided throughout this guide for features that are similar to those in WarehousePG. +Because WarehousePG is based on PostgreSQL 12.12, this guide assumes some familiarity with PostgreSQL. References to [PostgreSQL documentation](https://www.postgresql.org/docs/12/index.html) are provided throughout this guide for features that are similar to those in WarehousePG. This information is intended for system administrators responsible for administering a WarehousePG cluster.