Publish changes from main branch to the live website on GitHub pages

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;

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.

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.

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.
 
 <a id="topic_connmgmt">
 
@@ -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.
 
 <a id="resgroups">
 

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.

docs/whpg/6x/ref_guide/sql_commands/LOCK.md

@@ -1,35 +1,22 @@
 ---
 title: LOCK
-
 ---
 
-<a id="topic1"></a><a id="dv20941"></a><a id="sql_command_desc"></a>
-
 Locks a table.
 
-<a id="section2">
-
-</a>
-
 ## Synopsis
 
-<a id="sql_command_synopsis"></a>
-
 ```
 LOCK [TABLE] [ONLY] name [ * ] [, ...] [IN <lockmode> MODE] [NOWAIT] [MASTER ONLY]
 ```
 
 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
 ```
 
-<a id="section3">
-
-</a>
-
 ## 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.
 
-<a id="section4">
-
-</a>
-
 ## 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:
 
-    <a id="ul_cnt_mll_m4"></a><a id="dv157736"></a>
-    - 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.
-    <a id="dv157739"></a>
-    - 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`).
-    <a id="dv157742"></a>
-    - 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).
-    <a id="dv157745"></a>
-    - 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`.
-    <a id="dv157748"></a>
-    - 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`.
-    <a id="dv157751"></a>
-    - 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.
-    <a id="dv157754"></a>
-    - 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
+   <a id="lock_note"></a>
+
+   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
 
-<a id="section5">
+  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.
 
-</a>
+  ::: Note
+
+  This option is only supported in `ACCESS SHARE MODE`.
 
-<a id="section5"></a>
+  :::
 
 ## 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.
 
-<a id="section6">
-
-</a>
-
 ## 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;
 ```
 
-<a id="section7">
-
-</a>
-
 ## 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.
 
-<a id="section8">
-
-</a>
-
 ## See Also
 
 [BEGIN](BEGIN.md), [SET TRANSACTION](SET_TRANSACTION.md), [SELECT](SELECT.md)

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.
 ```
 

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;

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           |
 
 <a id="server_version_num"></a>