;
```
If disabling parallelism yields better or more consistent results, consider disabling it for specific queries at the session level using SET commands. For a broader impact, you might want to disable parallelism at the instance level by adjusting the relevant parameters in your cluster or instance parameter group. For more information, see [Amazon Aurora PostgreSQL parameters](AuroraPostgreSQL.Reference.ParameterGroups.md).
### Monitor parallel query usage
Use the following queries to gain visibility into parallel query activity and capacity:
Check active parallel worker processes:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
This query shows the number of active parallel worker processes. A high value may indicate that your `max\$1parallel\$1workers` is configured with a high value and you might want to consider reducing it.
Check concurrent parallel queries:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
This query returns the number of distinct leader processes that have launched parallel queries. A high number here indicates that multiple sessions are running parallel queries concurrently, which can increase demand on CPU and memory.
### Review and adjust parallel query settings
Review the following parameters to ensure they align with your workload:
+ `max_parallel_workers`: Total number of parallel workers across all sessions.
+ `max_parallel_workers_per_gather`: Max workers per query.
For OLAP workloads, increasing these values can improve performance. For OLTP workloads, lower values are generally preferred.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Optimize resource allocation
Monitor CPU utilization and consider adjusting the number of vCPUs if consistently high and if your application benefits from parallel queries. Ensure adequate memory is available for parallel operations.
+ Use Performance Insights metrics to determine if the system is CPU-bound.
+ Each parallel worker uses its own `work_mem`. Ensure total memory usage is within instance limits.
The parallel queries may consume very substantially more resources than non-parallel queries, because each worker process is a completely separate process which has roughly the same impact on the system as an additional user session. This should be taken into account when choosing a value for this setting, as well as when configuring other settings that control resource utilization, such as `work_mem`. For more information, see the [PostgreSQL documentation](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Resource limits such as `work_mem` are applied individually to each worker, which means the total utilization may be much higher across all processes than it would normally be for any single process.
Consider increasing vCPUs or tuning memory parameters if your workload is heavily parallelized.
### Investigate connection management
If experiencing connection exhaustion, review application connection pooling strategies. Consider implementing connection pooling at the application level if not already in use.
### Review and optimize maintenance operations
Coordinate index creation and other maintenance tasks to prevent resource contention. Consider scheduling these operations during off-peak hours. Avoid scheduling heavy maintenance (e.g., parallel index builds) during periods of high user query load. These operations can consume parallel workers and impact performance for regular queries.
### Utilize Query Plan Management (QPM)
In Aurora PostgreSQL, the Query Plan Management (QPM) feature is designed to ensure plan adaptability and stability, regardless of database environment changes that might cause query plan regression. For more information, see [Overview of Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.overview.md).QPM provides some control over the optimizer. Review approved plans in QPM to ensure they align with current parallelism settings. Update or remove outdated plans that may be forcing suboptimal parallel execution.
You can also fix the plans using pg\$1hint\$1plan. For more information, see [Fixing plans using pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). You can use the hint named `Parallel` to enforce parallel execution. For more information, see the [Hints for parallel plans](https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_table.md#hints-for-parallel-plans).
# IPC:ProcArrayGroupUpdate
The `IPC:ProcArrayGroupUpdate` event occurs when a session is waiting for the group leader to update the transaction status at the end of that operation. While PostgreSQL generally associates IPC type wait events with parallel query operations, this particular wait event is not specific to parallel queries.
**Topics**
+ [Supported engine versions](#apg-rpg-ipcprocarraygroup.supported)
+ [Context](#apg-rpg-ipcprocarraygroup.context)
+ [Likely causes of increased waits](#apg-rpg-ipcprocarraygroup.causes)
+ [Actions](#apg-rpg-ipcprocarraygroup.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
**Understanding the process array** – The process (proc) array is a shared memory structure in PostgreSQL. It holds information about all running processes, including transaction details. During transaction completion (`COMMIT` or `ROLLBACK`), the ProcArray needs to be updated to reflect the change and clear the transactionID from the array. The session attempting to finish its transaction must acquire an exclusive lock on the ProcArray. This prevents other processes from obtaining shared or exclusive locks on it.
**Group update mechanism** – While performing a COMMIT or ROLLBACK, if a backend process cannot obtain a ProcArrayLock in exclusive mode, it updates a special field called ProcArrayGroupMember. This adds the transaction to the list of sessions that intend to end. This backend process then sleeps and the time it sleeps is instrumented as the ProcArrayGroupUpdate wait event. The first process in the ProcArray with procArrayGroupMember, referred to as the leader process, acquires the ProcArrayLock in exclusive mode. It then clears the list of processes waiting for group transactionID clearing. Once this completes, the leader releases the ProcArrayLock and then wakes up all processes in this list, notifying them that their transaction is completed.
## Likely causes of increased waits
The more processes that are running, the longer a leader will hold on to a procArrayLock in exclusive mode. Consequently, the more write transactions end up in a group update scenario causing a potential pile up of processes waiting on the `ProcArrayGroupUpdate` wait event. In Database Insights' Top SQL view, you will see that COMMIT is the statement with the majority of this wait event. This is expected but will require deeper investigation into the specific write SQL being run to determine what appropriate action to take.
## Actions
We recommend different actions depending on the causes of your wait event. Identify `IPC:ProcArrayGroupUpdate` events by using Amazon RDS Performance Insights or by querying the PostgreSQL system view `pg_stat_activity`.
**Topics**
+ [Monitoring transaction commit and rollback operations](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Reducing concurrency](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementing connection pooling](#apg-rpg-ipcprocarraygroup.actions.pooling)
### Monitoring transaction commit and rollback operations
**Monitor commits and rollbacks** – An increased number of commits and rollbacks can lead to increased pressure on the ProcArray. For example, if a SQL statement begins to fail due to increased duplicate key violations, you may see an increase in rollbacks which can increase ProcArray contention and table bloat.
Amazon RDS Database Insights provides the PostgreSQL metrics `xact_commit` and `xact_rollback` to report the number of commits and rollbacks per second.
### Reducing concurrency
**Batching transactions** – Where possible, batch operations in single transactions to reduce commit/rollback operations.
**Limit concurrency** – Reduce the number of concurrently active transactions to alleviate lock contention on the ProcArray. While it will require some testing, reducing the total number of concurrent connections can reduce contention and maintain throughput.
### Implementing connection pooling
**Connection pooling solutions** – Use connection pooling to manage database connections efficiently, reducing the total number of backends and therefore the workload on the ProcArray. While it will require some testing, reducing the total number of concurrent connections can reduce contention and maintain throughput.
For more information, see [Connection pooling for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.connection_pooling.html).
**Reduce connection storms** – Similarly, a pattern of frequently creating and terminating connections causes additional pressure on the ProcArray. By reducing this pattern, overall contention is reduced.
# Lock:advisory
The `Lock:advisory` event occurs when a PostgreSQL application uses a lock to coordinate activity across multiple sessions.
**Topics**
+ [Relevant engine versions](#apg-waits.lockadvisory.context.supported)
+ [Context](#apg-waits.lockadvisory.context)
+ [Causes](#apg-waits.lockadvisory.causes)
+ [Actions](#apg-waits.lockadvisory.actions)
## Relevant engine versions
This wait event information is relevant for Aurora PostgreSQL versions 9.6 and higher.
## Context
PostgreSQL advisory locks are application-level, cooperative locks explicitly locked and unlocked by the user's application code. An application can use PostgreSQL advisory locks to coordinate activity across multiple sessions. Unlike regular, object- or row-level locks, the application has full control over the lifetime of the lock. For more information, see [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) in the PostgreSQL documentation.
Advisory locks can be released before a transaction ends or be held by a session across transactions. This isn't true for implicit, system-enforced locks, such as an access-exclusive lock on a table acquired by a `CREATE INDEX` statement.
For a description of the functions used to acquire (lock) and release (unlock) advisory locks, see [Advisory Lock Functions](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) in the PostgreSQL documentation.
Advisory locks are implemented on top of the regular PostgreSQL locking system and are visible in the `pg_locks` system view.
## Causes
This lock type is exclusively controlled by an application explicitly using it. Advisory locks that are acquired for each row as part of a query can cause a spike in locks or a long-term buildup.
These effects happen when the query is run in a way that acquires locks on more rows than are returned by the query. The application must eventually release every lock, but if locks are acquired on rows that aren't returned, the application can't find all of the locks.
The following example is from [Advisory Locks](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) in the PostgreSQL documentation.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
In this example, the `LIMIT` clause can only stop the query's output after the rows have already been internally selected and their ID values locked. This can happen suddenly when a growing data volume causes the planner to choose a different execution plan that wasn't tested during development. The buildup in this case happens because the application explicitly calls `pg_advisory_unlock` for every ID value that was locked. However, in this case it can't find the set of locks acquired on rows that weren't returned. Because the locks are acquired on the session level, they aren't released automatically at the end of the transaction.
Another possible cause for spikes in blocked lock attempts is unintended conflicts. In these conflicts, unrelated parts of the application share the same lock ID space by mistake.
## Actions
Review application usage of advisory locks and detail where and when in the application flow each type of advisory lock is acquired and released.
Determine whether a session is acquiring too many locks or a long-running session isn't releasing locks early enough, leading to a slow buildup of locks. You can correct a slow buildup of session-level locks by ending the session using `pg_terminate_backend(pid)`.
A client waiting for an advisory lock appears in `pg_stat_activity` with `wait_event_type=Lock` and `wait_event=advisory`. You can obtain specific lock values by querying the `pg_locks` system view for the same `pid`, looking for `locktype=advisory` and `granted=f`.
You can then identify the blocking session by querying `pg_locks` for the same advisory lock having `granted=t`, as shown in the following example.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
All of the advisory lock API functions have two sets of arguments, either one `bigint` argument or two `integer` arguments:
+ For the API functions with one `bigint` argument, the upper 32 bits are in `pg_locks.classid` and the lower 32 bits are in `pg_locks.objid`.
+ For the API functions with two `integer` arguments, the first argument is `pg_locks.classid` and the second argument is `pg_locks.objid`.
The `pg_locks.objsubid` value indicates which API form was used: `1` means one `bigint` argument; `2` means two `integer` arguments.
# Lock:extend
The `Lock:extend` event occurs when a backend process is waiting to lock a relation to extend it while another process has a lock on that relation for the same purpose.
**Topics**
+ [Supported engine versions](#apg-waits.lockextend.context.supported)
+ [Context](#apg-waits.lockextend.context)
+ [Likely causes of increased waits](#apg-waits.lockextend.causes)
+ [Actions](#apg-waits.lockextend.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
The event `Lock:extend` indicates that a backend process is waiting to extend a relation that another backend process holds a lock on while it's extending that relation. Because only one process at a time can extend a relation, the system generates a `Lock:extend` wait event. `INSERT`, `COPY`, and `UPDATE` operations can generate this event.
## Likely causes of increased waits
When the `Lock:extend` event appears more than normal, possibly indicating a performance problem, typical causes include the following:
**Surge in concurrent inserts or updates to the same table **
There might be an increase in the number of concurrent sessions with queries that insert into or update the same table.
**Insufficient network bandwidth**
The network bandwidth on the DB instance might be insufficient for the storage communication needs of the current workload. This can contribute to storage latency that causes an increase in `Lock:extend` events.
## Actions
We recommend different actions depending on the causes of your wait event.
**Topics**
+ [Reduce concurrent inserts and updates to the same relation](#apg-waits.lockextend.actions.action1)
+ [Increase network bandwidth](#apg-waits.lockextend.actions.increase-network-bandwidth)
### Reduce concurrent inserts and updates to the same relation
First, determine whether there's an increase in `tup_inserted` and `tup_updated` metrics and an accompanying increase in this wait event. If so, check which relations are in high contention for insert and update operations. To determine this, query the `pg_stat_all_tables` view for the values in `n_tup_ins` and `n_tup_upd` fields. For information about the `pg_stat_all_tables` view, see [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) in the PostgreSQL documentation.
To get more information about blocking and blocked queries, query `pg_stat_activity` as in the following example:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
After you identify relations that contribute to increase `Lock:extend` events, use the following techniques to reduce the contention:
+ Find out whether you can use partitioning to reduce contention for the same table. Separating inserted or updated tuples into different partitions can reduce contention. For information about partitioning, see [Managing PostgreSQL partitions with the pg\$1partman extension](PostgreSQL_Partitions.md).
+ If the wait event is mainly due to update activity, consider reducing the relation's fillfactor value. This can reduce requests for new blocks during the update. The fillfactor is a storage parameter for a table that determines the maximum amount of space for packing a table page. It's expressed as a percentage of the total space for a page. For more information about the fillfactor parameter, see [CREATE TABLE](https://www.postgresql.org/docs/13/sql-createtable.html) in the PostgreSQL documentation.
**Important**
We highly recommend that you test your system if you change the fillfactor because changing this value can negatively impact performance, depending on your workload.
### Increase network bandwidth
To see whether there's an increase in write latency, check the `WriteLatency` metric in CloudWatch. If there is, use the `WriteThroughput` and `ReadThroughput` Amazon CloudWatch metrics to monitor the storage related traffic on the DB cluster. These metrics can help you to determine if network bandwidth is sufficient for the storage activity of your workload.
If your network bandwidth isn't enough, increase it. If your DB instance is reaching the network bandwidth limits, the only way to increase the bandwidth is to increase your DB instance size.
For more information about CloudWatch metrics, see [Amazon CloudWatch metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). For information about network performance for each DB instance class, see [Hardware specifications for DB instance classesfor Aurora](Concepts.DBInstanceClass.Summary.md).
# Lock:Relation
The `Lock:Relation` event occurs when a query is waiting to acquire a lock on a table or view (relation) that's currently locked by another transaction.
**Topics**
+ [Supported engine versions](#apg-waits.lockrelation.context.supported)
+ [Context](#apg-waits.lockrelation.context)
+ [Likely causes of increased waits](#apg-waits.lockrelation.causes)
+ [Actions](#apg-waits.lockrelation.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
Most PostgreSQL commands implicitly use locks to control concurrent access to data in tables. You can also use these locks explicitly in your application code with the `LOCK` command. Many lock modes aren't compatible with each other, and they can block transactions when they're trying to access the same object. When this happens, Aurora PostgreSQL generates a `Lock:Relation` event. Some common examples are the following:
+ Exclusive locks such as `ACCESS EXCLUSIVE` can block all concurrent access. Data definition language (DDL) operations such as `DROP TABLE`, `TRUNCATE`, `VACUUM FULL`, and `CLUSTER` acquire `ACCESS EXCLUSIVE` locks implicitly. `ACCESS EXCLUSIVE` is also the default lock mode for `LOCK TABLE` statements that don't specify a mode explicitly.
+ Using `CREATE INDEX (without CONCURRENT)` on a table conflicts with data manipulation language (DML) statements `UPDATE`, `DELETE`, and `INSERT`, which acquire `ROW EXCLUSIVE` locks.
For more information about table-level locks and conflicting lock modes, see [Explicit Locking](https://www.postgresql.org/docs/13/explicit-locking.html) in the PostgreSQL documentation.
Blocking queries and transactions typically unblock in one of the following ways:
+ Blocking query – The application can cancel the query or the user can end the process. The engine can also force the query to end because of a session's statement-timeout or a deadlock detection mechanism.
+ Blocking transaction – A transaction stops blocking when it runs a `ROLLBACK` or `COMMIT` statement. Rollbacks also happen automatically when sessions are disconnected by a client or by network issues, or are ended. Sessions can be ended when the database engine is shut down, when the system is out of memory, and so forth.
## Likely causes of increased waits
When the `Lock:Relation` event occurs more frequently than normal, it can indicate a performance issue. Typical causes include the following:
**Increased concurrent sessions with conflicting table locks**
There might be an increase in the number of concurrent sessions with queries that lock the same table with conflicting locking modes.
**Maintenance operations**
Health maintenance operations such as `VACUUM` and `ANALYZE` can significantly increase the number of conflicting locks. `VACUUM FULL` acquires an `ACCESS EXCLUSIVE` lock, and `ANALYZE` acquires a `SHARE UPDATE EXCLUSIVE` lock. Both types of locks can cause a `Lock:Relation` wait event. Application data maintenance operations such as refreshing a materialized view can also increase blocked queries and transactions.
**Locks on reader instances**
There might be a conflict between the relation locks held by the writer and readers. Currently, only `ACCESS EXCLUSIVE` relation locks are replicated to reader instances. However, the `ACCESS EXCLUSIVE` relation lock will conflict with any `ACCESS SHARE` relation locks held by the reader. This can cause an increase in lock relation wait events on the reader.
## Actions
We recommend different actions depending on the causes of your wait event.
**Topics**
+ [Reduce the impact of blocking SQL statements](#apg-waits.lockrelation.actions.reduce-blocks)
+ [Minimize the effect of maintenance operations](#apg-waits.lockrelation.actions.maintenance)
+ [Check for reader locks](#apg-waits.lockrelation.actions.readerlocks)
### Reduce the impact of blocking SQL statements
To reduce the impact of blocking SQL statements, modify your application code where possible. Following are two common techniques for reducing blocks:
+ Use the `NOWAIT` option – Some SQL commands, such as `SELECT` and `LOCK` statements, support this option. The `NOWAIT` directive cancels the lock-requesting query if the lock can't be acquired immediately. This technique can help prevent a blocking session from causing a pile-up of blocked sessions behind it.
For example: Assume that transaction A is waiting on a lock held by transaction B. Now, if B requests a lock on a table that’s locked by transaction C, transaction A might be blocked until transaction C completes. But if transaction B uses a `NOWAIT` when it requests the lock on C, it can fail fast and ensure that transaction A doesn't have to wait indefinitely.
+ Use `SET lock_timeout` – Set a `lock_timeout` value to limit the time a SQL statement waits to acquire a lock on a relation. If the lock isn't acquired within the timeout specified, the transaction requesting the lock is canceled. Set this value at the session level.
### Minimize the effect of maintenance operations
Maintenance operations such as `VACUUM` and `ANALYZE` are important. We recommend that you don't turn them off because you find `Lock:Relation` wait events related to these maintenance operations. The following approaches can minimize the effect of these operations:
+ Run maintenance operations manually during off-peak hours.
+ To reduce `Lock:Relation` waits caused by autovacuum tasks, perform any needed autovacuum tuning. For information about tuning autovacuum, see [ Working with PostgreSQL autovacuum on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) in the * Amazon RDS User Guide*.
### Check for reader locks
You can see how concurrent sessions on a writer and readers might be holding locks that block each other. One way to do this is by running queries that return the lock type and relation. In the table, you can find a sequence of queries to two such concurrent sessions, a writer session and a reader session.
The replay process waits for the duration of `max_standby_streaming_delay` before canceling the reader query. As shown in the example, the lock timeout of 100ms is well below the default `max_standby_streaming_delay` of 30 seconds. The lock times out before it's an issue.
| Sequence event | Session | Command or Output |
| --- | --- | --- |
| Sets an environment variable called READER with the specified value and tries to connect to the DB instance with this endpoint. | Reader session | CLI command: export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com
psql -h $READER
Output:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Sets an environment variable called WRITER and tries to connect to the DB instance with this endpoint . | Writer session | CLI command: export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER
Output:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| The writer session creates table t1 on the writer instance. | Writer session | PostgreSQL query: postgres=> CREATE TABLE t1(b integer);
CREATE TABLE
|
| If there are no conflicting queries on the writer, the ACCESS EXCLUSIVE lock is acquired on the writer immediately. | Writer session | `ACCESS EXCLUSIVE` lock enabled |
| The reader session sets a lock timeout interval of 100 milliseconds. | Reader session | PostgreSQL query: postgres=> SET lock_timeout=100;
SET
|
| The reader session tries to read data from table t1 on the reader instance. | Reader session | PostgreSQL query: postgres=> SELECT * FROM t1;
Sample output:
```
b
---
(0 rows)
``` |
| The writer session drops t1. | Writer session | PostgreSQL query: postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>
|
| The query times out and is canceled on the reader. | Reader session | PostgreSQL query: postgres=> SELECT * FROM t1;
Sample output:
```
ERROR: canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
^
``` |
| To determine the cause of the error. the reader session queries `pg_locks` and `pg_stat_activity` | Reader session | PostgreSQL query: postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;
|
| The result indicates that the `aurora wal replay` process is holding an `ACCESS EXCLUSIVE` lock on table t1. | Reader session | Query result: locktype | relation | mode | backend_type
----------+----------+---------------------+-------------------
relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)
|
# Lock:transactionid
The `Lock:transactionid` event occurs when a transaction is waiting for a row-level lock.
**Topics**
+ [Supported engine versions](#apg-waits.locktransactionid.context.supported)
+ [Context](#apg-waits.locktransactionid.context)
+ [Likely causes of increased waits](#apg-waits.locktransactionid.causes)
+ [Actions](#apg-waits.locktransactionid.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
The event `Lock:transactionid` occurs when a transaction is trying to acquire a row-level lock that has already been granted to a transaction that is running at the same time. The session that shows the `Lock:transactionid` wait event is blocked because of this lock. After the blocking transaction ends in either a `COMMIT` or `ROLLBACK` statement, the blocked transaction can proceed.
The multiversion concurrency control semantics of Aurora PostgreSQL guarantee that readers don't block writers and writers don't block readers. For row-level conflicts to occur, blocking and blocked transactions must issue conflicting statements of the following types:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
The statement `SELECT … FOR KEY SHARE` is a special case. The database uses the clause `FOR KEY SHARE` to optimize the performance of referential integrity. A row-level lock on a row can block `INSERT`, `UPDATE`, and `DELETE` commands on other tables that reference the row.
## Likely causes of increased waits
When this event appears more than normal, the cause is typically `UPDATE`, `SELECT … FOR UPDATE`, or `SELECT … FOR KEY SHARE` statements combined with the following conditions.
**Topics**
+ [High concurrency](#apg-waits.locktransactionid.concurrency)
+ [Idle in transaction](#apg-waits.locktransactionid.idle)
+ [Long-running transactions](#apg-waits.locktransactionid.long-running)
### High concurrency
Aurora PostgreSQL can use granular row-level locking semantics. The probability of row-level conflicts increases when the following conditions are met:
+ A highly concurrent workload contends for the same rows.
+ Concurrency increases.
### Idle in transaction
Sometimes the `pg_stat_activity.state` column shows the value `idle in transaction`. This value appears for sessions that have started a transaction, but haven't yet issued a `COMMIT` or `ROLLBACK`. If the `pg_stat_activity.state` value isn't `active`, the query shown in `pg_stat_activity` is the most recent one to finish running. The blocking session isn't actively processing a query because an open transaction is holding a lock.
If an idle transaction acquired a row-level lock, it might be preventing other sessions from acquiring it. This condition leads to frequent occurrence of the wait event `Lock:transactionid`. To diagnose the issue, examine the output from `pg_stat_activity` and `pg_locks`.
### Long-running transactions
Transactions that run for a long time get locks for a long time. These long-held locks can block other transactions from running.
## Actions
Row-locking is a conflict among `UPDATE`, `SELECT … FOR UPDATE`, or `SELECT … FOR KEY SHARE` statements. Before attempting a solution, find out when these statements are running on the same row. Use this information to choose a strategy described in the following sections.
**Topics**
+ [Respond to high concurrency](#apg-waits.locktransactionid.actions.problem)
+ [Respond to idle transactions](#apg-waits.locktransactionid.actions.find-blocker)
+ [Respond to long-running transactions](#apg-waits.locktransactionid.actions.concurrency)
### Respond to high concurrency
If concurrency is the issue, try one of the following techniques:
+ Lower the concurrency in the application. For example, decrease the number of active sessions.
+ Implement a connection pool. To learn how to pool connections with RDS Proxy, see [Amazon RDS Proxyfor Aurora](rds-proxy.md).
+ Design the application or data model to avoid contending `UPDATE` and `SELECT … FOR UPDATE` statements. You can also decrease the number of foreign keys accessed by `SELECT … FOR KEY SHARE` statements.
### Respond to idle transactions
If `pg_stat_activity.state` shows `idle in transaction`, use the following strategies:
+ Turn on autocommit wherever possible. This approach prevents transactions from blocking other transactions while waiting for a `COMMIT` or `ROLLBACK`.
+ Search for code paths that are missing `COMMIT`, `ROLLBACK`, or `END`.
+ Make sure that the exception handling logic in your application always has a path to a valid `end of transaction`.
+ Make sure that your application processes query results after ending the transaction with `COMMIT` or `ROLLBACK`.
### Respond to long-running transactions
If long-running transactions are causing the frequent occurrence of `Lock:transactionid`, try the following strategies:
+ Keep row locks out of long-running transactions.
+ Limit the length of queries by implementing autocommit whenever possible.
# Lock:tuple
The `Lock:tuple` event occurs when a backend process is waiting to acquire a lock on a tuple.
**Topics**
+ [Supported engine versions](#apg-waits.locktuple.context.supported)
+ [Context](#apg-waits.locktuple.context)
+ [Likely causes of increased waits](#apg-waits.locktuple.causes)
+ [Actions](#apg-waits.locktuple.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
The event `Lock:tuple` indicates that a backend is waiting to acquire a lock on a tuple while another backend holds a conflicting lock on the same tuple. The following table illustrates a scenario in which sessions generate the `Lock:tuple` event.
| Time | Session 1 | Session 2 | Session 3 |
| --- | --- | --- | --- |
| t1 | Starts a transaction. | | |
| t2 | Updates row 1. | | |
| t3 | | Updates row 1. The session acquires an exclusive lock on the tuple and then waits for session 1 to release the lock by committing or rolling back. | |
| t4 | | | Updates row 1. The session waits for session 2 to release the exclusive lock on the tuple. |
Or you can simulate this wait event by using the benchmarking tool `pgbench`. Configure a high number of concurrent sessions to update the same row in a table with a custom SQL file.
To learn more about conflicting lock modes, see [Explicit Locking](https://www.postgresql.org/docs/current/explicit-locking.html) in the PostgreSQL documentation. To learn more about `pgbench`, see [pgbench](https://www.postgresql.org/docs/current/pgbench.html) in the PostgreSQL documentation.
## Likely causes of increased waits
When this event appears more than normal, possibly indicating a performance problem, typical causes include the following:
+ A high number of concurrent sessions are trying to acquire a conflicting lock for the same tuple by running `UPDATE` or `DELETE` statements.
+ Highly concurrent sessions are running a `SELECT` statement using the `FOR UPDATE` or `FOR NO KEY UPDATE` lock modes.
+ Various factors drive application or connection pools to open more sessions to execute the same operations. As new sessions are trying to modify the same rows, DB load can spike, and `Lock:tuple` can appear.
For more information, see [Row-Level Locks](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) in the PostgreSQL documentation.
## Actions
We recommend different actions depending on the causes of your wait event.
**Topics**
+ [Investigate your application logic](#apg-waits.locktuple.actions.problem)
+ [Find the blocker session](#apg-waits.locktuple.actions.find-blocker)
+ [Reduce concurrency when it is high](#apg-waits.locktuple.actions.concurrency)
+ [Troubleshoot bottlenecks](#apg-waits.locktuple.actions.bottlenecks)
### Investigate your application logic
Find out whether a blocker session has been in the `idle in transaction` state for long time. If so, consider ending the blocker session as a short-term solution. You can use the `pg_terminate_backend` function. For more information about this function, see [Server Signaling Functions](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) in the PostgreSQL documentation.
For a long-term solution, do the following:
+ Adjust the application logic.
+ Use the `idle_in_transaction_session_timeout` parameter. This parameter ends any session with an open transaction that has been idle for longer than the specified amount of time. For more information, see [Client Connection Defaults](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) in the PostgreSQL documentation.
+ Use autocommit as much as possible. For more information, see [SET AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) in the PostgreSQL documentation.
### Find the blocker session
While the `Lock:tuple` wait event is occurring, identify the blocker and blocked session by finding out which locks depend on one another. For more information, see [Lock dependency information](https://wiki.postgresql.org/wiki/Lock_dependency_information) in the PostgreSQL wiki. To analyze past `Lock:tuple` events, use the Aurora function `aurora_stat_backend_waits`.
The following example queries all sessions, filtering on `tuple` and ordering by `wait_time`.
```
--AURORA_STAT_BACKEND_WAITS
SELECT a.pid,
a.usename,
a.app_name,
a.current_query,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
left(query,80) as current_query,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND usename<>'rdsadmin') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we
WHERE we.event_name = 'tuple'
ORDER BY a.wait_time;
pid | usename | app_name | current_query | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+---------+----------+------------------------------------------------+-------------------+--------------------+---------------+-----------+------------+-------+-----------
32136 | sys | psql | /*session3*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000018
11999 | sys | psql | /*session4*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000024
```
### Reduce concurrency when it is high
The `Lock:tuple` event might occur constantly, especially in a busy workload time. In this situation, consider reducing the high concurrency for very busy rows. Often, just a few rows control a queue or the Boolean logic, which makes these rows very busy.
You can reduce concurrency by using different approaches based in the business requirement, application logic, and workload type. For example, you can do the following:
+ Redesign your table and data logic to reduce high concurrency.
+ Change the application logic to reduce high concurrency at the row level.
+ Leverage and redesign queries with row-level locks.
+ Use the `NOWAIT` clause with retry operations.
+ Consider using optimistic and hybrid-locking logic concurrency control.
+ Consider changing the database isolation level.
### Troubleshoot bottlenecks
The `Lock:tuple` can occur with bottlenecks such as CPU starvation or maximum usage of Amazon EBS bandwidth. To reduce bottlenecks, consider the following approaches:
+ Scale up your instance class type.
+ Optimize resource-intensive queries.
+ Change the application logic.
+ Archive data that is rarely accessed.
# LWLock:buffer\$1content (BufferContent)
The `LWLock:buffer_content` event occurs when a session is waiting to read or write a data page in memory while another session has that page locked for writing. In Aurora PostgreSQL 13 and higher, this wait event is called `BufferContent`.
**Topics**
+ [Supported engine versions](#apg-waits.lockbuffercontent.context.supported)
+ [Context](#apg-waits.lockbuffercontent.context)
+ [Likely causes of increased waits](#apg-waits.lockbuffercontent.causes)
+ [Actions](#apg-waits.lockbuffercontent.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
To read or manipulate data, PostgreSQL accesses it through shared memory buffers. To read from the buffer, a process gets a lightweight lock (LWLock) on the buffer content in shared mode. To write to the buffer, it gets that lock in exclusive mode. Shared locks allow other processes to concurrently acquire shared locks on that content. Exclusive locks prevent other processes from getting any type of lock on it.
The `LWLock:buffer_content` (`BufferContent`) event indicates that multiple processes are attempting to get lightweight locks (LWLocks) on contents of a specific buffer.
## Likely causes of increased waits
When the `LWLock:buffer_content` (`BufferContent`) event appears more than normal, possibly indicating a performance problem, typical causes include the following:
**Increased concurrent updates to the same data**
There might be an increase in the number of concurrent sessions with queries that update the same buffer content. This contention can be more pronounced on tables with a lot of indexes.
**Workload data is not in memory**
When data that the active workload is processing is not in memory, these wait events can increase. This effect is because processes holding locks can keep them longer while they perform disk I/O operations.
**Excessive use of foreign key constraints**
Foreign key constraints can increase the amount of time a process holds onto a buffer content lock. This effect is because read operations require a shared buffer content lock on the referenced key while that key is being updated.
## Actions
We recommend different actions depending on the causes of your wait event. You might identify `LWLock:buffer_content` (`BufferContent`) events by using Amazon RDS Performance Insights or by querying the view `pg_stat_activity`.
**Topics**
+ [Improve in-memory efficiency](#apg-waits.lockbuffercontent.actions.in-memory)
+ [Reduce usage of foreign key constraints](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [Remove unused indexes](#apg-waits.lockbuffercontent.actions.indexes)
+ [Remove duplicate indexes](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [Drop or REINDEX invalid indexes](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [Use partial indexes](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [Remove table and index bloat](#apg-waits.lockbuffercontent.actions.bloat)
### Improve in-memory efficiency
To increase the chance that active workload data is in memory, partition tables or scale up your instance class. For information about DB instance classes, see [Amazon AuroraDB instance classes](Concepts.DBInstanceClass.md).
Monitor the `BufferCacheHitRatio` metric, which measures the percentage of requests served by the buffer cache of a DB instance in your DB cluster. This metric provides insight into the amount of data being served from memory. A high hit ratio indicates that your DB instance has sufficient memory available for your working data set, while a low ratio suggests that your queries are frequently accessing data from storage.
The cache read hit per table and cache read hit per index under Memory setting section of the [PG Collector](https://github.com/awslabs/pg-collector) report can provide insights into the tables and indexes cache hit ratio.
### Reduce usage of foreign key constraints
Investigate workloads experiencing high numbers of `LWLock:buffer_content` (`BufferContent`) wait events for usage of foreign key constraints. Remove unnecessary foreign key constraints.
### Remove unused indexes
For workloads experiencing high numbers of `LWLock:buffer_content` (`BufferContent`) wait events, identify unused indexes and remove them.
The unused indexes section of the [PG Collector](https://github.com/awslabs/pg-collector) report can provide insights into the unused indexes in the database.
### Remove duplicate indexes
Identify duplicate indexes and remove them.
The duplicate indexes section of the [PG Collector](https://github.com/awslabs/pg-collector) report can provide insights into the duplicate indexes in the database.
### Drop or REINDEX invalid indexes
Invalid indexes typically occur when using `CREATE INDEX CONCURRENTLY` or `REINDEX CONCURRENTLY` and the command fails or is aborted.
Invalid indexes can't be used for queries, though they will still be updated and take up disk space.
The Invalid indexes section of the [PG Collector](https://github.com/awslabs/pg-collector) report can provide insights into the invalid indexes in the database.
### Use partial indexes
Partial indexes can be leveraged to enhance query performance and reduce index size. A partial index is an index built over a subset of a table, with the subset defined by a conditional expression. As detailed in the [partial index](https://www.postgresql.org/docs/current/indexes-partial.html) documentation, partial indexes can reduce the overhead of maintaining indexes, as PostgreSQL does not need to update the index in all cases.
### Remove table and index bloat
Excessive table and index bloat can negatively impact database performance. Bloated tables and indexes increase the active working set size, degrading in-memory efficiency. Additionally, bloat increases storage costs and slows query execution. To diagnose bloat, refer to the [Diagnosing table and index bloat](AuroraPostgreSQL.diag-table-ind-bloat.md). Further, the Fragmentation (Bloat) section of the [PG Collector](https://github.com/awslabs/pg-collector) report can provide insights into tables and indexes bloat.
To address table and index bloat, there are a few options:
**VACUUM FULL**
`VACUUM FULL` creates a new copy of the table, copying over only the live tuples, and then replaces the old table with the new one while holding an `ACCESS EXCLUSIVE` lock. This prevents any reading or writing to the table, which can cause an outage. Additionally, `VACUUM FULL` will take longer if the table is large.
**pg\$1repack**
The `pg_repack` is helpful in situations where `VACUUM FULL` might not be suitable. It creates a new table that contains the data of the bloated table, tracks the changes from the original table, and then replaces the original table with the new one. It doesn't lock the original table for read or write operations while it's building the new table. For more information, for how to use `pg_repack`, see [Removing bloat with pg\$1repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html) and [pg\$1repack](https://reorg.github.io/pg_repack/).
**REINDEX**
The `REINDEX` command can be leveraged to address index bloat. `REINDEX` writes a new version of the index without the dead pages or the empty or nearly-empty pages, thereby reducing the space consumption of the index. For detailed information about the [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html) command, please refer to the REINDEX documentation.
After removing bloat from tables and indexes, it may be necessary to increase the autovacuum frequency on those tables. Implementing aggressive autovacuum settings at the table level can help prevent future bloat from occurring. For more information, please refer to the documentation on [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html).
# LWLock:buffer\$1mapping
This event occurs when a session is waiting to associate a data block with a buffer in the shared buffer pool.
**Note**
This event appears as `LWLock:buffer_mapping` in Aurora PostgreSQL version 12 and lower, and `LWLock:BufferMapping` in version 13 and higher.
**Topics**
+ [Supported engine versions](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Context](#apg-waits.lwl-buffer-mapping.context)
+ [Causes](#apg-waits.lwl-buffer-mapping.causes)
+ [Actions](#apg-waits.lwl-buffer-mapping.actions)
## Supported engine versions
This wait event information is relevant for Aurora PostgreSQL version 9.6 and higher.
## Context
The *shared buffer pool* is an Aurora PostgreSQL memory area that holds all pages that are or were being used by processes. When a process needs a page, it reads the page into the shared buffer pool. The `shared_buffers` parameter sets the shared buffer size and reserves a memory area to store the table and index pages. If you change this parameter, make sure to restart the database. For more information, see [Shared buffers](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).
The `LWLock:buffer_mapping` wait event occurs in the following scenarios:
+ A process searches the buffer table for a page and acquires a shared buffer mapping lock.
+ A process loads a page into the buffer pool and acquires an exclusive buffer mapping lock.
+ A process removes a page from the pool and acquires an exclusive buffer mapping lock.
## Causes
When this event appears more than normal, possibly indicating a performance problem, the database is paging in and out of the shared buffer pool. Typical causes include the following:
+ Large queries
+ Bloated indexes and tables
+ Full table scans
+ A shared pool size that is smaller than the working set
## Actions
We recommend different actions depending on the causes of your wait event.
**Topics**
+ [Monitor buffer-related metrics](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Assess your indexing strategy](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Reduce the number of buffers that must be allocated quickly](#apg-waits.lwl-buffer-mapping.actions.buffers)
### Monitor buffer-related metrics
When `LWLock:buffer_mapping` waits spike, investigate the buffer hit ratio. You can use these metrics to get a better understanding of what is happening in the buffer cache. Examine the following metrics:
`BufferCacheHitRatio`
This Amazon CloudWatch metric measures the percentage of requests that are served by the buffer cache of a DB instance in your DB cluster. You might see this metric decrease in the lead-up to the `LWLock:buffer_mapping` wait event.
`blks_hit`
This Performance Insights counter metric indicates the number of blocks that were retrieved from the shared buffer pool. After the `LWLock:buffer_mapping` wait event appears, you might observe a spike in `blks_hit`.
`blks_read`
This Performance Insights counter metric indicates the number of blocks that required I/O to be read into the shared buffer pool. You might observe a spike in `blks_read` in the lead-up to the `LWLock:buffer_mapping` wait event.
### Assess your indexing strategy
To confirm that your indexing strategy is not degrading performance, check the following:
Index bloat
Ensure that index and table bloat aren't leading to unnecessary pages being read into the shared buffer. If your tables contain unused rows, consider archiving the data and removing the rows from the tables. You can then rebuild the indexes for the resized tables.
Indexes for frequently used queries
To determine whether you have the optimal indexes, monitor DB engine metrics in Performance Insights. The `tup_returned` metric shows the number of rows read. The `tup_fetched` metric shows the number of rows returned to the client. If `tup_returned` is significantly larger than `tup_fetched`, the data might not be properly indexed. Also, your table statistics might not be current.
### Reduce the number of buffers that must be allocated quickly
To reduce the `LWLock:buffer_mapping` wait events, try to reduce the number of buffers that must be allocated quickly. One strategy is to perform smaller batch operations. You might be able to achieve smaller batches by partitioning your tables.
# LWLock:BufferIO (IPC:BufferIO)
The `LWLock:BufferIO` event occurs when Aurora PostgreSQL or RDS for PostgreSQL is waiting for other processes to finish their input/output (I/O) operations when concurrently trying to access a page. Its purpose is for the same page to be read into the shared buffer.
**Topics**
+ [Relevant engine versions](#apg-waits.lwlockbufferio.context.supported)
+ [Context](#apg-waits.lwlockbufferio.context)
+ [Causes](#apg-waits.lwlockbufferio.causes)
+ [Actions](#apg-waits.lwlockbufferio.actions)
## Relevant engine versions
This wait event information is relevant for all Aurora PostgreSQL versions. For Aurora PostgreSQL 12 and earlier versions this wait event is named as lwlock:buffer\$1io whereas in Aurora PostgreSQL 13 version it is named as lwlock:bufferio. From Aurora PostgreSQL 14 version BufferIO wait event moved from `LWLock` to `IPC` wait event type (IPC:BufferIO).
## Context
Each shared buffer has an I/O lock that is associated with the `LWLock:BufferIO` wait event, each time a block (or a page) has to be retrieved outside the shared buffer pool.
This lock is used to handle multiple sessions that all require access to the same block. This block has to be read from outside the shared buffer pool, defined by the `shared_buffers` parameter.
As soon as the page is read inside the shared buffer pool, the `LWLock:BufferIO` lock is released.
**Note**
The `LWLock:BufferIO` wait event precedes the [IO:DataFileRead](apg-waits.iodatafileread.md) wait event. The `IO:DataFileRead` wait event occurs while data is being read from storage.
For more information on lightweight locks, see [Locking Overview](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Causes
Common causes for the `LWLock:BufferIO` event to appear in top waits include the following:
+ Multiple backends or connections trying to access the same page that's also pending an I/O operation
+ The ratio between the size of the shared buffer pool (defined by the `shared_buffers` parameter) and the number of buffers needed by the current workload
+ The size of the shared buffer pool not being well balanced with the number of pages being evicted by other operations
+ Large or bloated indexes that require the engine to read more pages than necessary into the shared buffer pool
+ Lack of indexes that forces the DB engine to read more pages from the tables than necessary
+ Sudden spikes for database connections trying to perform operations on the same page
## Actions
We recommend different actions depending on the causes of your wait event:
+ Observe Amazon CloudWatch metrics for correlation between sharp decreases in the `BufferCacheHitRatio` and `LWLock:BufferIO` wait events. This effect can mean that you have a small shared buffers setting. You might need to increase it or scale up your DB instance class. You can split your workload into more reader nodes.
+ Verify whether you have unused indexes, then remove them.
+ Use partitioned tables (which also have partitioned indexes). Doing this helps to keep index reordering low and reduces its impact.
+ Avoid indexing columns unnecessarily.
+ Prevent sudden database connection spikes by using a connection pool.
+ Restrict the maximum number of connections to the database as a best practice.
# LWLock:lock\$1manager
This event occurs when the Aurora PostgreSQL engine maintains the shared lock's memory area to allocate, check, and deallocate a lock when a fast path lock isn't possible.
**Topics**
+ [Supported engine versions](#apg-waits.lw-lock-manager.context.supported)
+ [Context](#apg-waits.lw-lock-manager.context)
+ [Likely causes of increased waits](#apg-waits.lw-lock-manager.causes)
+ [Actions](#apg-waits.lw-lock-manager.actions)
## Supported engine versions
This wait event information is relevant for Aurora PostgreSQL version 9.6 and higher.
## Context
When you issue a SQL statement, Aurora PostgreSQL records locks to protect the structure, data, and integrity of your database during concurrent operations. The engine can achieve this goal using a fast path lock or a path lock that isn't fast. A path lock that isn't fast is more expensive and creates more overhead than a fast path lock.
### Fast path locking
To reduce the overhead of locks that are taken and released frequently, but that rarely conflict, backend processes can use fast path locking. The database uses this mechanism for locks that meet the following criteria:
+ They use the DEFAULT lock method.
+ They represent a lock on a database relation rather than a shared relation.
+ They are weak locks that are unlikely to conflict.
+ The engine can quickly verify that no conflicting locks can possibly exist.
The engine can't use fast path locking when either of the following conditions is true:
+ The lock doesn't meet the preceding criteria.
+ No more slots are available for the backend process.
For more information about fast path locking, see [fast path](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) in the PostgreSQL lock manager README and [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html) in the PostgreSQL documentation.
### Example of a scaling problem for the lock manager
In this example, a table named `purchases` stores five years of data, partitioned by day. Each partition has two indexes. The following sequence of events occurs:
1. You query many days worth of data, which requires the database to read many partitions.
1. The database creates a lock entry for each partition. If partition indexes are part of the optimizer access path, the database creates a lock entry for them, too.
1. When the number of requested locks entries for the same backend process is higher than 16, which is the value of `FP_LOCK_SLOTS_PER_BACKEND`, the lock manager uses the non–fast path lock method.
Modern applications might have hundreds of sessions. If concurrent sessions are querying the parent without proper partition pruning, the database might create hundreds or even thousands of non–fast path locks. Typically, when this concurrency is higher than the number of vCPUs, the `LWLock:lock_manager` wait event appears.
**Note**
The `LWLock:lock_manager` wait event isn't related to the number of partitions or indexes in a database schema. Instead, it's related to the number of non–fast path locks that the database must control.
## Likely causes of increased waits
When the `LWLock:lock_manager` wait event occurs more than normal, possibly indicating a performance problem, the most likely causes of sudden spikes are as follows:
+ Concurrent active sessions are running queries that don't use fast path locks. These sessions also exceed the maximum vCPU.
+ A large number of concurrent active sessions are accessing a heavily partitioned table. Each partition has multiple indexes.
+ The database is experiencing a connection storm. By default, some applications and connection pool software create more connections when the database is slow. This practice makes the problem worse. Tune your connection pool software so that connection storms don't occur.
+ A large number of sessions query a parent table without pruning partitions.
+ A data definition language (DDL), data manipulation language (DML), or a maintenance command exclusively locks either a busy relation or tuples that are frequently accessed or modified.
## Actions
We recommend different actions depending on the causes of your wait event.
**Topics**
+ [Use partition pruning](#apg-waits.lw-lock-manager.actions.pruning)
+ [Remove unnecessary indexes](#apg-waits.lw-lock-manager.actions.indexes)
+ [Tune your queries for fast path locking](#apg-waits.lw-lock-manager.actions.tuning)
+ [Tune for other wait events](#apg-waits.lw-lock-manager.actions.other-waits)
+ [Reduce hardware bottlenecks](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [Use a connection pooler](#apg-waits.lw-lock-manager.actions.pooler)
+ [Upgrade your Aurora PostgreSQL version](#apg-waits.lw-lock-manager.actions.pg-version)
### Use partition pruning
*Partition pruning* is a query optimization strategy that excludes unneeded partitions from table scans, thereby improving performance. Partition pruning is turned on by default. If it is turned off, turn it on as follows.
```
SET enable_partition_pruning = on;
```
Queries can take advantage of partition pruning when their `WHERE` clause contains the column used for the partitioning. For more information, see [Partition Pruning](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) in the PostgreSQL documentation.
### Remove unnecessary indexes
Your database might contain unused or rarely used indexes. If so, consider deleting them. Do either of the following:
+ Learn how to find unnecessary indexes by reading [Unused Indexes](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) in the PostgreSQL wiki.
+ Run PG Collector. This SQL script gathers database information and presents it in a consolidated HTML report. Check the "Unused indexes" section. For more information, see [pg-collector](https://github.com/awslabs/pg-collector) in the AWS Labs GitHub repository.
### Tune your queries for fast path locking
To find out whether your queries use fast path locking, query the `fastpath` column in the `pg_locks` table. If your queries aren't using fast path locking, try to reduce number of relations per query to fewer than 16.
### Tune for other wait events
If `LWLock:lock_manager` is first or second in the list of top waits, check whether the following wait events also appear in the list:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
If the preceding events appear high in the list, consider tuning these wait events first. These events can be a driver for `LWLock:lock_manager`.
### Reduce hardware bottlenecks
You might have a hardware bottleneck, such as CPU starvation or maximum usage of your Amazon EBS bandwidth. In these cases, consider reducing the hardware bottlenecks. Consider the following actions:
+ Scale up your instance class.
+ Optimize queries that consume large amounts of CPU and memory.
+ Change your application logic.
+ Archive your data.
For more information about CPU, memory, and EBS network bandwidth, see [Amazon RDS Instance Types](https://aws.amazon.com/rds/instance-types/).
### Use a connection pooler
If your total number of active connections exceeds the maximum vCPU, more OS processes require CPU than your instance type can support. In this case, consider using or tuning a connection pool. For more information about the vCPUs for your instance type, see [Amazon RDS Instance Types](https://aws.amazon.com/rds/instance-types/).
For more information about connection pooling, see the following resources:
+ [Amazon RDS Proxyfor Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Connection Pools and Data Sources](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) in the *PostgreSQL Documentation*
### Upgrade your Aurora PostgreSQL version
If your current version of Aurora PostgreSQL is lower than 12, upgrade to version 12 or higher. PostgreSQL versions 12 and 13 have an improved partition mechanism. For more information about version 12, see [PostgreSQL 12.0 Release Notes]( https://www.postgresql.org/docs/release/12.0/). For more information about upgrading Aurora PostgreSQL, see [Database engine updates for Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
# LWLock:MultiXact
The `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU`, and `LWLock:MultiXactOffsetSLRU` wait events indicate that a session is waiting to retrieve a list of transactions that modifies the same row in a given table.
+ `LWLock:MultiXactMemberBuffer` – A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a multixact member.
+ `LWLock:MultiXactMemberSLRU` – A process is waiting to access the simple least-recently used (SLRU) cache for a multixact member.
+ `LWLock:MultiXactOffsetBuffer` – A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a multixact offset.
+ `LWLock:MultiXactOffsetSLRU` – A process is waiting to access the simple least-recently used (SLRU) cache for a multixact offset.
**Topics**
+ [Supported engine versions](#apg-waits.xactsync.context.supported)
+ [Context](#apg-waits.lwlockmultixact.context)
+ [Likely causes of increased waits](#apg-waits.lwlockmultixact.causes)
+ [Actions](#apg-waits.lwlockmultixact.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
A *multixact* is a data structure that stores a list of transaction IDs (XIDs) that modify the same table row. When a single transaction references a row in a table, the transaction ID is stored in the table header row. When multiple transactions reference the same row in a table, the list of transaction IDs is stored in the multixact data structure. The multixact wait events indicate that a session is retrieving from the data structure the list of transactions that refer to a given row in a table.
## Likely causes of increased waits
Three common causes of multixact use are as follows:
+ **Sub-transactions from explicit savepoints** – Explicitly creating a savepoint in your transactions spawns new transactions for the same row. For example, using `SELECT FOR UPDATE`, then `SAVEPOINT`, and then `UPDATE`.
Some drivers, object-relational mappers (ORMs), and abstraction layers have configuration options for automatically wrapping all operations with savepoints. This can generate many multixact wait events in some workloads. The PostgreSQL JDBC Driver's `autosave` option is an example of this. For more information, see [pgJDBC](https://jdbc.postgresql.org/) in the PostgreSQL JDBC documentation. Another example is the PostgreSQL ODBC driver and its `protocol` option. For more information, see [psqlODBC Configuration Options](https://odbc.postgresql.org/docs/config.html) in the PostgreSQL ODBC driver documentation.
+ **Sub-transactions from PL/pgSQL EXCEPTION clauses** – Each `EXCEPTION` clause that you write in your PL/pgSQL functions or procedures creates a `SAVEPOINT` internally.
+ **Foreign keys** – Multiple transactions acquire a shared lock on the parent record.
When a given row is included in a multiple transaction operation, processing the row requires retrieving transaction IDs from the `multixact` listings. If lookups can't get the multixact from the memory cache, the data structure must be read from the Aurora storage layer. This I/O from storage means that SQL queries can take longer. Memory cache misses can start occurring with heavy usage due to a large number of multiple transactions. All these factors contribute to an increase in this wait event.
## Actions
We recommend different actions depending on the causes of your wait event. Some of these actions can help in immediate reduction of the wait events. But, others might require investigation and correction to scale your workload.
**Topics**
+ [Perform vacuum freeze on tables with this wait event](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Increase autovacuum frequency on tables with this wait event](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Increase memory parameters](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Reduce long-running transactions](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Long term actions](#apg-waits.lwlockmultixact.actions.longactions)
### Perform vacuum freeze on tables with this wait event
If this wait event spikes suddenly and affects your production environment, you can use any of the following temporary methods to reduce its count.
+ Use *VACUUM FREEZE* on the affected table or table partition to resolve the issue immediately. For more information, see [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Use the VACUUM (FREEZE, INDEX\$1CLEANUP FALSE) clause to perform a quick vacuum by skipping the indexes. For more information, see [Vacuuming a table as quickly as possible](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Increase autovacuum frequency on tables with this wait event
After scanning all tables in all databases, VACUUM will eventually remove multixacts, and their oldest multixact values are advanced. For more information, see [Multixacts and Wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). To keep the LWLock:MultiXact wait events to its minimum, you must run the VACUUM as often as necessary. To do so, ensure that the VACUUM in your Aurora PostgreSQL DB cluster is configured optimally.
If using VACUUM FREEZE on the affected table or table partition resolves the wait event issue, we recommend using a scheduler, such as `pg_cron`, to perform the VACUUM instead of adjusting autovacuum at the instance level.
For the autovacuum to happen more frequently, you can reduce the value of the storage parameter `autovacuum_multixact_freeze_max_age` in the affected table. For more information, see [autovacuum\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Increase memory parameters
You can optimize memory usage for multixact caches by adjusting the following parameters. These settings control how much memory is reserved for these caches, which can help reduce multixact wait events in your workload. We recommend starting with the following values:
For Aurora PostgreSQL 17 and later:
+ `multixact_offset_buffers` = 128
+ `multixact_member_buffers` = 256
For Aurora PostgreSQL 16 and earlier:
+ `multixact_offsets_cache_size` = 128
+ `multixact_members_cache_size` = 256
**Note**
In Aurora PostgreSQL 17, parameter names were changed from `multixact_offsets_cache_size` to `multixact_offset_buffers` and from `multixact_members_cache_size` to `multixact_member_buffers` to align with community PostgreSQL 17.
You can set these parameters at the cluster level so that all instances in your cluster remain consistent. We recommend you to test and adjust the values to best suit your specific workload requirements and instance class. You must reboot the writer instance for the parameter changes to take effect.
The parameters are expressed in terms of multixact cache entries. Each cache entry uses `8 KB` of memory. To calculate the total memory reserved, multiply each parameter value by `8 KB`. For example, if you set a parameter to 128, the total reserved memory would be `128 * 8 KB = 1 MB`.
### Reduce long-running transactions
Long-running transaction causes the vacuum to retain its information until the transaction is committed or until the read-only transaction is closed. We recommend that you proactively monitor and manage long-running transactions. For more information, see [Database has long running idle in transaction connection](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Try to modify your application to avoid or minimize your use of long-running transactions.
### Long term actions
Examine your workload to discover the cause for the multixact spillover. You must fix the issue in order to scale your workload and reduce the wait event.
+ You must analyze the DDL (data definition language) used to create your tables. Make sure that the table structures and indexes are well designed.
+ When the affected tables have foreign keys, determine whether they are needed or if there is another way to enforce referential integrity.
+ When a table has large unused indexes, it can cause autovacuum to not fit your workload and might block it from running. To avoid this, check for unused indexes and remove them completely. For more information, see [Managing autovacuum with large indexes](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Reduce the use of savepoints in your transactions.
# LWLock:pg\$1stat\$1statements
The LWLock:pg\$1stat\$1statements wait event occurs when the `pg_stat_statements` extension takes an exclusive lock on the hash table that tracks SQL statements. This happens in the following scenarios:
+ When the number of tracked statements reaches the configured `pg_stat_statements.max` parameter value and there is a need to make room for more entries, the extension performs a sort on the number of calls, removes the 5% of the least-executed statements, and re-populates the hash with the remaining entries.
+ When `pg_stat_statements` performs a `garbage collection` operation to the `pgss_query_texts.stat` file on disk and rewrites the file.
**Topics**
+ [Supported engine versions](#apg-rpg-lwlockpgstat.supported)
+ [Context](#apg-rpg-lwlockpgstat.context)
+ [Likely causes of increased waits](#apg-rpg-lwlockpgstat.causes)
+ [Actions](#apg-rpg-lwlockpgstat.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Context
**Understanding the pg\$1stat\$1statements extension** – The pg\$1stat\$1statements extension tracks SQL statement execution statistics in a hash table. The extension tracks SQL statements up to the limit defined by the `pg_stat_statements.max` parameter. This parameter determines the maximum number of statements that can be tracked which corresponds to the maximum number of rows in the pg\$1stat\$1statements view.
**Statement statistics persistence** – The extension persists statement statistics across instance restarts by:
+ Writing data to a file named pg\$1stat\$1statements.stat
+ Using the pg\$1stat\$1statements.save parameter to control persistence behavior
When pg\$1stat\$1statements.save is set to:
+ on (default): Statistics are saved at shutdown and reloaded at server start
+ off: Statistics are neither saved at shutdown nor reloaded at server start
**Query text storage** – The extension stores the text of tracked queries in a file named `pgss_query_texts.stat`. This file can grow to double the average size of all tracked SQL statements before garbage collection occurs. The extension requires an exclusive lock on the hash table during cleanup operations and rewrite `pgss_query_texts.stat` file.
**Statement deallocation process** – When the number of tracked statements reaches the `pg_stat_statements.max` limit and new statements need to be tracked, the extension:
+ Takes an exclusive lock (LWLock:pg\$1stat\$1statements) on the hash table.
+ Loads existing data into local memory.
+ Performs a quicksort based on the number of calls.
+ Removes the least-called statements (bottom 5%).
+ Re-populates the hash table with the remaining entries.
**Monitoring statement deallocation** – In PostgreSQL 14 and later, you can monitor statement deallocation using the pg\$1stat\$1statements\$1info view. This view includes a dealloc column that shows how many times statements were deallocated to make room for new ones
If the deallocation of statements occurs frequently, it will lead to more frequent garbage collection of the `pgss_query_texts.stat` file on disk.
## Likely causes of increased waits
The typical causes of increased `LWLock:pg_stat_statements` waits include:
+ An increase in the number of unique queries used by the application.
+ The `pg_stat_statements.max` parameter value being small compared to the number of unique queries being used.
## Actions
We recommend different actions depending on the causes of your wait event. You might identify `LWLock:pg_stat_statements` events by using Amazon RDS Performance Insights or by querying the view `pg_stat_activity`.
Adjust the following `pg_stat_statements` parameters to control tracking behavior and reduce LWLock:pg\$1stat\$1 statements wait events.
**Topics**
+ [Disable pg\$1stat\$1statements.track parameter](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Increase pg\$1stat\$1statements.max parameter](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Disable pg\$1stat\$1statements.track\$1utility parameter](#apg-rpg-lwlockpgstat.actions.disableutility)
### Disable pg\$1stat\$1statements.track parameter
If the LWLock:pg\$1stat\$1statements wait event is adversely impacting database performance, and a rapid solution is required before further analysis of the `pg_stat_statements` view to identify the root cause, the `pg_stat_statements.track` parameter can be disabled by setting it to `none`. This will disable the collection of statement statistics.
### Increase pg\$1stat\$1statements.max parameter
To reduce deallocation and minimize garbage collection of the `pgss_query_texts.stat` file on disk, increase the value of the `pg_stat_statements.max` parameter. The default value is `5,000`.
**Note**
The `pg_stat_statements.max` parameter is static. You must restart your DB instance to apply any changes to this parameter.
### Disable pg\$1stat\$1statements.track\$1utility parameter
You can analyze the pg\$1stat\$1statements view to determine which utility commands are consuming the most resources tracked by `pg_stat_statements`.
The `pg_stat_statements.track_utility` parameter controls whether the module tracks utility commands, which include all commands except SELECT, INSERT, UPDATE, DELETE, and MERGE. By default, this parameter is set to `on`.
For example, when your application uses many savepoint queries, which are inherently unique, it can increase statement deallocation. To address this, you can disable the `pg_stat_statements.track_utility` parameter to stop `pg_stat_statements` from tracking savepoint queries.
**Note**
The `pg_stat_statements.track_utility` parameter is a dynamic parameter. You can change its value without restarting your database instance.
**Example of unique save point queries in pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 introduces several enhancements for utility command tracking:
+ Savepoint names are now displayed as constants.
+ Global Transaction IDs (GIDs) of two-phase commit commands are now displayed as constants.
+ Names of DEALLOCATE statements are shown as constants.
+ CALL parameters are now displayed as constants.
# Timeout:PgSleep
The `Timeout:PgSleep` event occurs when a server process has called the `pg_sleep` function and is waiting for the sleep timeout to expire.
**Topics**
+ [Supported engine versions](#apg-waits.timeoutpgsleep.context.supported)
+ [Likely causes of increased waits](#apg-waits.timeoutpgsleep.causes)
+ [Actions](#apg-waits.timeoutpgsleep.actions)
## Supported engine versions
This wait event information is supported for all versions of Aurora PostgreSQL.
## Likely causes of increased waits
This wait event occurs when an application, stored function, or user issues a SQL statement that calls one of the following functions:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
The preceding functions delay execution until the specified number of seconds have elapsed. For example, `SELECT pg_sleep(1)` pauses for 1 second. For more information, see [Delaying Execution](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) in the PostgreSQL documentation.
## Actions
Identify the statement that was running the `pg_sleep` function. Determine if the use of the function is appropriate.
# Tuning Aurora PostgreSQL with Amazon DevOps Guru proactive insights
DevOps Guru proactive insights detects conditions on your Aurora PostgreSQL DB clusters that can cause problems, and lets you know about them before they occur. Proactive insights can alert you to a long running idle in transaction connection. For more information about troubleshooting long running idle in transaction connections, see [Database has long running idle in transaction connection](#proactive-insights.idle-txn)
DevOps Guru can do the following:
+ Prevent many common database issues by cross-checking your database configuration against common recommended settings.
+ Alert you to critical issues in your fleet that, if left unchecked, can lead to larger problems later.
+ Alert you to newly discovered problems.
Every proactive insight contains an analysis of the cause of the problem and recommendations for corrective actions.
For more information about Amazon DevOps Guru for Amazon RDS, see [Analyzing Aurora performance anomalies with Amazon DevOps Guru for Amazon RDS](devops-guru-for-rds.md).
## Database has long running idle in transaction connection
A connection to the database has been in the `idle in transaction` state for more than 1800 seconds.
**Topics**
+ [Supported engine versions](#proactive-insights.idle-txn.context.supported)
+ [Context](#proactive-insights.idle-txn.context)
+ [Likely causes for this issue](#proactive-insights.idle-txn.causes)
+ [Actions](#proactive-insights.idle-txn.actions)
+ [Relevant metrics](#proactive-insights.idle-txn.metrics)
### Supported engine versions
This insight information is supported for all versions of Aurora PostgreSQL.
### Context
A transaction in the `idle in transaction` state can hold locks that block other queries. It can also prevent `VACUUM` (including autovacuum) from cleaning up dead rows, leading to index or table bloat or transaction ID wraparound.
### Likely causes for this issue
A transaction initiated in an interactive session with BEGIN or START TRANSACTION hasn't ended by using a COMMIT, ROLLBACK, or END command. This causes the transaction to move to `idle in transaction` state.
### Actions
You can find idle transactions by querying `pg_stat_activity`.
In your SQL client, run the following query to list all connections in `idle in transaction` state and to order them by duration:
```
SELECT now() - state_change as idle_in_transaction_duration, now() - xact_start as xact_duration,*
FROM pg_stat_activity
WHERE state = 'idle in transaction'
AND xact_start is not null
ORDER BY 1 DESC;
```
We recommend different actions depending on the causes of your insight.
**Topics**
+ [End transaction](#proactive-insights.idle-txn.actions.end-txn)
+ [Terminate the connection](#proactive-insights.idle-txn.actions.end-connection)
+ [Configure the idle\$1in\$1transaction\$1session\$1timeout parameter](#proactive-insights.idle-txn.actions.parameter)
+ [Check the AUTOCOMMIT status](#proactive-insights.idle-txn.actions.autocommit)
+ [Check the transaction logic in your application code](#proactive-insights.idle-txn.actions.app-logic)
#### End transaction
When you initiate a transaction in an interactive session with BEGIN or START TRANSACTION, it moves to `idle in transaction` state. It remains in this state until you end the transaction by issuing a COMMIT, ROLLBACK, END command or disconnect the connection completely to roll back the transaction.
#### Terminate the connection
Terminate the connection with an idle transaction using the following query:
```
SELECT pg_terminate_backend(pid);
```
pid is the process ID of the connection.
#### Configure the idle\$1in\$1transaction\$1session\$1timeout parameter
Configure the `idle_in_transaction_session_timeout` parameter in the parameter group. The advantage of configuring this parameter is that it does not require a manual intervention to terminate the long idle in transaction. For more information on this parameter, see [the PostgreSQL documentation](https://www.postgresql.org/docs/current/runtime-config-client.html).
The following message will be reported in the PostgreSQL log file after the connection is terminated, when a transaction is in the idle\$1in\$1transaction state for longer than the specified time.
```
FATAL: terminating connection due to idle in transaction timeout
```
#### Check the AUTOCOMMIT status
AUTOCOMMIT is turned on by default. But if it is accidentally turned off in the client ensure that you turn it back on.
+ In your psql client, run the following command:
```
postgres=> \set AUTOCOMMIT on
```
+ In pgadmin, turn it on by choosing the AUTOCOMMIT option from the down arrow.
![\[In pgadmin, choose AUTOCOMMIT to turn it on.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-insight-pgadmin-autocommit.png)
#### Check the transaction logic in your application code
Investigate your application logic for possible problems. Consider the following actions:
+ Check if the JDBC auto commit is set true in your application. Also, consider using explicit `COMMIT` commands in your code.
+ Check your error handling logic to see whether it closes a transaction after errors.
+ Check whether your application is taking long to process the rows returned by a query while the transaction is open. If so, consider coding the application to close the transaction before processing the rows.
+ Check whether a transaction contains many long-running operations. If so, divide a single transaction into multiple transactions.
### Relevant metrics
The following PI metrics are related to this insight:
+ idle\$1in\$1transaction\$1count - Number of sessions in `idle in transaction` state.
+ idle\$1in\$1transaction\$1max\$1time - The duration of the longest running transaction in the `idle in transaction` state.
# Best practices with Amazon Aurora PostgreSQL
Following, you can find several best practices for managing your Amazon Aurora PostgreSQL DB cluster. Be sure to also review basic maintenance tasks. For more information, see [Performance and scaling for Amazon Aurora PostgreSQL](AuroraPostgreSQL.Managing.md).
**Topics**
+ [Avoiding slow performance, automatic restart, and failover for Aurora PostgreSQL DB instances](#AuroraPostgreSQL.BestPractices.Avoiding)
+ [Diagnosing table and index bloat](AuroraPostgreSQL.diag-table-ind-bloat.md)
+ [Managing high object counts in Amazon Aurora PostgreSQL](PostgreSQL.HighObjectCount.md)
+ [Improved memory management in Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.memory.management.md)
+ [Fast failover with Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md)
+ [Fast recovery after failover with cluster cache management for Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md)
+ [Managing Aurora PostgreSQL connection churn with pooling](AuroraPostgreSQL.BestPractices.connection_pooling.md)
+ [Dead connection handling in PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [Tuning memory parameters for Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md)
+ [Using Amazon CloudWatch metrics to analyze resource usage for Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md)
+ [Using logical replication to perform a major version upgrade for Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md)
+ [Managing custom casts in Aurora PostgreSQL](PostgreSQL.CustomCasts.md)
+ [Best Practices for Parallel Queries in Aurora PostgreSQL](PostgreSQL.ParallelQueries.md)
+ [Troubleshooting storage issues in Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.TroubleshootingStorage.md)
## Avoiding slow performance, automatic restart, and failover for Aurora PostgreSQL DB instances
If you're running a heavy workload or workloads that spike beyond the allocated resources of your DB instance, you can exhaust the resources on which you're running your application and Aurora database. To get metrics on your database instance such as CPU utilization, memory usage, and number of database connections used, you can refer to the metrics provided by Amazon CloudWatch, Performance Insights, and Enhanced Monitoring. For more information on monitoring your DB instance, see [Monitoring metrics in an Amazon Aurora cluster](MonitoringAurora.md).
If your workload exhausts the resources you're using, your DB instance might slow down, restart, or even fail over to another DB instance. To avoid this, monitor your resource utilization, examine the workload running on your DB instance, and make optimizations where necessary. If optimizations don't improve the instance metrics and mitigate the resource exhaustion, consider scaling up your DB instance before you reach its limits. For more information on available DB instance classes and their specifications, see [Amazon AuroraDB instance classes](Concepts.DBInstanceClass.md).
# Diagnosing table and index bloat
You can use PostgreSQL Multiversion Concurrency Control (MVCC) to help preserve data integrity. PostgreSQL MVCC works by saving an internal copy of updated or deleted rows (also called *tuples*) until a transaction is either committed or rolled back. This saved internal copy is invisible to users. However, table bloat can occur when those invisible copies aren't cleaned up regularly by the VACUUM or AUTOVACUUM utilities. Unchecked, table bloat can incur increased storage costs and slow your processing speed.
In many cases, the default settings for VACUUM or AUTOVACUUM on Aurora are sufficient for handling unwanted table bloat. However, you may want to check for bloat if your application is experiencing the following conditions:
+ Processes a large number of transactions in a relatively short time between VACUUM processes.
+ Performs poorly and runs out of storage.
To get started, gather the most accurate information about how much space is used by dead tuples and how much you can recover by cleaning up the table and index bloat. To do so, use the `pgstattuple` extension to gather statistics on your Aurora cluster. For more information, see [pgstattuple](https://www.postgresql.org/docs/current/pgstattuple.html). Privileges to use the `pgstattuple` extension are limited to the `pg_stat_scan_tables` role and database superusers.
To create the `pgstattuple` extension on Aurora, connect a client session to the cluster, for example, psql or pgAdmin, and use the following command:
```
CREATE EXTENSION pgstattuple;
```
Create the extension in each database that you want to profile. After creating the extension, use the command line interface (CLI) to measure how much unusable space you can reclaim. Before gathering statistics, modify the cluster parameter group by setting AUTOVACUUM to 0. A setting of 0 prevents Aurora from automatically cleaning up any dead tuples left behind by your application, which can impact the accuracy of the results. Enter the following command to create a simple table:
```
postgres=> CREATE TABLE lab AS SELECT generate_series (0,100000);
SELECT 100001
```
In the following example, we run the query with AUTOVACUUM turned on for the DB cluster. The `dead_tuple_count` is 0, which indicates that the AUTOVACUUM has deleted the obsolete data or tuples from the PostgreSQL database.
To use `pgstattuple` to gather information about the table, specify the name of a table or an object identifier (OID) in the query:
```
postgres=> SELECT * FROM pgstattuple('lab');
```
```
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
3629056 | 100001 | 2800028 | 77.16 | 0 | 0 | 0 | 16616 | 0.46
(1 row)
```
In the following query, we turn off AUTOVACUUM and enter a command that deletes 25,000 rows from the table. As a result, the `dead_tuple_count` increases to 25000.
```
postgres=> DELETE FROM lab WHERE generate_series < 25000;
DELETE 25000
```
```
SELECT * FROM pgstattuple('lab');
```
```
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
3629056 | 75001 | 2100028 | 57.87 | 25000 | 700000 | 19.29 | 16616 | 0.46
(1 row)
```
To reclaim those dead tuples, start a VACUUM process.
## Observing bloat without interrupting your application
Settings on an Aurora cluster are optimized to provide the best practices for most workloads. However, you might want to optimize a cluster to better suit your applications and use patterns. In this case, you can use the `pgstattuple` extension without disrupting a busy application. To do so, perform the following steps:
1. Clone your Aurora instance.
1. Modify the parameter file to turn off AUTOVACUUM in the clone.
1. Perform a `pgstattuple` query while testing the clone with a sample workload or with pgbench, which is a program for running benchmark tests on PostgreSQL. For more information, see [pgbench](https://www.postgresql.org/docs/current/pgbench.html).
After running your applications and viewing the result, use pg\$1repack or VACUUM FULL on the restored copy and compare the differences. If you see a significant drop in the dead\$1tuple\$1count, dead\$1tuple\$1len, or dead\$1tuple\$1percent, then adjust the vacuum schedule on your production cluster to minimize the bloat.
## Avoiding bloat in temporary tables
If your application creates temporary tables, make sure that your application removes those temporary tables when they’re no longer needed. Autovacuum processes don’t locate temporary tables. Left unchecked, temporary tables can quickly create database bloat. Moreover, the bloat can extend into the system tables, which are the internal tables that track PostgreSQL objects and attributes, like pg\$1attribute and pg\$1depend.
When a temporary table is no longer needed, you can use a TRUNCATE statement to empty the table and free up the space. Then, manually vacuum the pg\$1attribute and pg\$1depend tables. Vacuuming these tables ensures that creating and truncating/deleting temporary tables continually isn't adding tuples and contributing to system bloat.
You can avoid this problem while creating a temporary table by including the following syntax that deletes the new rows when content is committed:
```
CREATE TEMP TABLE IF NOT EXISTS table_name(table_description) ON COMMIT DELETE ROWS;
```
The `ON COMMIT DELETE ROWS` clause truncates the temporary table when the transaction is committed.
## Avoiding bloat in indexes
When you change an indexed field in a table, the index update results in one or more dead tuples in that index. By default, the autovacuum process cleans up bloat in indexes, but that cleanup uses a significant amount of time and resources. To specify index cleanup preferences when you create a table, include the vacuum\$1index\$1cleanup clause. By default, at table creation time, the clause is set to AUTO, which means that the server decides if your index requires cleanup when it vacuums the table. You can set the clause to ON to turn on index cleanup for a specific table, or OFF to turn off index cleanup for that table. Remember, turning off index cleanup might save time, but can potentially lead to a bloated index.
You can manually control index cleanup when you VACUUM a table at the command line. To vacuum a table and remove dead tuples from the indexes, include the INDEX\$1CLEANUP clause with a value of ON and the table name:
```
acctg=> VACUUM (INDEX_CLEANUP ON) receivables;
INFO: aggressively vacuuming "public.receivables"
VACUUM
```
To vacuum a table without cleaning the indexes, specify a value of OFF:
```
acctg=> VACUUM (INDEX_CLEANUP OFF) receivables;
INFO: aggressively vacuuming "public.receivables"
VACUUM
```
# Managing high object counts in Amazon Aurora PostgreSQL
While PostgreSQL limitations are theoretical, having extremely high object counts in a database will cause noticeable performance impact to various operations. This documentation covers several common object types that, when having a high total count can lead to several possible impacts.
The following table provides a summary of object types and their potential impacts:
**Object types and potential impacts**
| Type of Object | Autovacuum | Logical Replication | Major Version Upgrade | pg\$1dump / pg\$1restore | General Performance | Instance Restart |
| --- | --- | --- | --- | --- | --- | --- |
| [Relations](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Temporary tables](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Unlogged tables](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partitions](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [Temporary files](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Sequences](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Large objects](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relations
There is not a specific hard limit regarding the number of tables in a PostgreSQL database. The theoretical limit is extremely high, but there are other practical limits that need to be kept in mind during database design.
**Impact: Autovacuum falling behind**
Autovacuum can struggle to keep up with transaction ID growth or table bloat due to lack of workers compared to amount of work.
**Recommended action:** There are several factors for tuning autovacuum to keep up properly with a given number of tables and given workload. See [Best practices for working with PostgreSQL autovacuum](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.html#AuroraPostgreSQL.BestPractices.Autovacuum) for suggestions on how to determine appropriate autovacuum settings. Use the [postgres\$1get\$1av\$1diag utility](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.html) to monitor problems with transaction ID growth.
**Impact: Major version upgrade / pg\$1dump and restore**
Amazon RDS uses the "--link" option during pg\$1upgrade execution to avoid having to make copies of datafiles, the schema metadata is still required to be restored into the new version of the database. Even with parallel pg\$1restore, if there are a significant number of relations this will increase the amount of downtime.
**Impact: General performance degradation**
General performance degradation due to catalog size. Each table and its associated columns will add to `pg_attribute`, `pg_class` and `pg_depend` tables which are frequently used in normal database operations. There won't be a specific wait event visible, but shared buffer efficiency will be impacted.
**Recommended action:** Regularly check table bloat for these specific tables and occasionally perform a `VACUUM FULL` on these specific tables. Be aware that `VACUUM FULL` on catalog tables requires an `ACCESS EXCLUSIVE` lock which means no other queries will be able to access them until the operation completes.
**Approximate threshold:** [Millions](#PostgreSQL.HighObjectCount.Note)
## Temporary tables
Using temporary tables is useful for test data or intermediate results and is a common pattern seen in many database engines. The implications of heavy use in PostgreSQL must be understood to avoid some of the pitfalls. Each temporary table create and drop will add rows to system catalog tables, which when they become bloated, will cause general performance issues.
**Impact: Autovacuum falling behind**
Temporary tables aren't vacuumed by autovacuum but will hold on to transaction IDs during their existence and can lead to wraparound if not removed.
**Recommended action:** Temporary tables will live for the duration of the session that created them or can be dropped manually. A best practice of avoiding long-running transactions with temporary tables will prevent these tables from contributing to maximum used transaction ID growth.
**Impact: General performance degradation**
General performance degradation due to catalog size. When sessions continuously create and drop temporary tables, it will add to `pg_attribute`, `pg_class` and `pg_depend` tables which are frequently used in normal database operations. There won't be a specific wait event visible, but shared buffer efficiency will be impacted.
**Recommended action:**
+ Regularly check table bloat for these specific tables and occasionally perform a `VACUUM FULL` on these specific tables. Be aware that `VACUUM FULL` on catalog tables requires an `ACCESS EXCLUSIVE` lock which means no other queries will be able to access them until the operation completes.
+ If temporary tables are heavily used, prior to a major version upgrade, a `VACUUM FULL` of these specific catalog tables is highly recommended to reduce downtime.
**General best practices:**
+ Reduce the use of temporary tables by using common table expressions to produce intermediate results. These can sometimes complicate the queries needed, but will eliminate the impacts listed above.
+ Reuse temporary tables by using the `TRUNCATE` command to clear the contents instead of doing drop/create steps. This will also eliminate the problem of transaction ID growth caused by temporary tables.
**Approximate threshold:** [Tens of thousands](#PostgreSQL.HighObjectCount.Note)
## Unlogged tables
Unlogged tables can offer performance gains as they won't generate any WAL information. They must be used carefully as they offer no durability during database crash recovery as they will be truncated. This is an expensive operation in PostgreSQL as each unlogged table is truncated serially. While this operation is fast for a low number of unlogged tables, when they number in the thousands it can start to add notable delay during startup.
**Impact: Logical replication**
Unlogged tables are generally not included in logical replication, including [Blue/Green Deployments](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html), because logical replication relies on the WAL to capture and transfer changes. Read more on how to configure Aurora PostgreSQL to [replicate unlogged tables](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-unlogged-tables.html#aurora-postgresql-unlogged-tables-logicalrep).
**Impact: Reader Nodes**
You can access unlogged tables only from the writer node in the Aurora DB cluster. See [Working with unlogged tables in Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-unlogged-tables.html) for full details.
**General best practices:**
+ Unlogged tables provide limited performance benefits in Aurora PostgreSQL compared to standard PostgreSQL, so evaluate whether normal tables are more appropriate.
**Approximate threshold:** [Thousands](#PostgreSQL.HighObjectCount.Note)
## Partitions
Partitioning can increase query performance and provide a logical organization of data. In ideal scenarios, partitioning is organized so that partition pruning can be used during query planning and execution. Using too many partitions can have negative impacts on query performance and database maintenance. The choice of how to partition a table should be made carefully, as the performance of query planning and execution can be negatively affected by poor design. See [PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-partitioning.html) for details about partitioning.
**Impact: General performance degradation**
Sometimes planning time overhead will increase and explain plans for your queries will become more complicated, making it difficult to identify tuning opportunities. For PostgreSQL versions earlier than 18, many partitions with high workload can lead to `LWLock:LockManager` waits.
**Recommended action:** Determine a minimum number of partitions that will allow you to complete both the organization of your data while at the same time providing performant query execution.
**Impact: Maintenance complexity**
Very high number of partitions will introduce maintenance difficulties like pre-creation and removal. Autovacuum will treat partitions as normal relations and have to perform regular cleanup, therefore requiring enough workers to complete the task.
**Recommended action:**
+ Ensure you precreate partitions so that workload isn't blocked when a new partition is needed (for example, monthly based partitions) and old partitions are rolled off.
+ Ensure you have enough autovacuum workers to perform normal cleanup maintenance of all partitions.
**Approximate threshold:** [Hundreds](#PostgreSQL.HighObjectCount.Note)
## Temporary files
Different than temporary tables mentioned above, temporary files are created by PostgreSQL when a complex query might perform several sort or hash operations at the same time, with each operation using instance memory to store results up to the value specified in the `work_mem` parameter. When the instance memory is not sufficient, temporary files are created to store the results. See [Managing temporary files](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL.ManagingTempFiles.html) for more details on temporary files. If your workload generates high numbers of these files, there can be several impacts.
**Impact: FreeLocalStorage consumption**
Temporary files are a necessary part of PostgreSQL when query results are unable to fit in work\$1mem. Generally this is fine. However, when the workload uses this extensively, that indicates large queries are continually running and you will observe a decrease in FreeLocalStorage. See [Managing temporary files](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL.ManagingTempFiles.html) for more details.
**General best practices:**
+ Monitor your temp file usage with [Performance Insights](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.html).
+ Tune queries that are generating significant temporary files to see if it's possible to reduce the total number of temp files.
**Approximate threshold:** [Thousands](#PostgreSQL.HighObjectCount.Note)
## Sequences
Sequences are the underlying object used for auto-incrementing columns in PostgreSQL and they provide uniqueness and a key for the data. These can be used on individual tables with no consequence during normal operations with one exception of logical replication.
In PostgreSQL, logical replication does not currently replicate a sequence's current value to any subscriber. To learn more, see the [Restrictions page in PostgreSQL documentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Impact: Extended switchover time**
If you plan to use [Blue/Green Deployments](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) for any type of configuration change or upgrade, it is important to understand the impact of a high number of sequences on switchover. One of the last phases of a switchover will synchronize the current value of sequences, and if there are several thousand, this will increase the overall switchover time.
**Recommended action:** If your database workload would allow for the use of a shared UUID instead of a sequence-per-table approach, this would cut down on the synchronization step during a switchover.
**Approximate threshold:** [Thousands](#PostgreSQL.HighObjectCount.Note)
## Large objects
Large objects are stored in a single system table named pg\$1largeobject. Each large object also has an entry in the system table pg\$1largeobject\$1metadata. These objects are created, modified and cleaned up much differently than standard relations. Large objects are not handled by autovacuum and must be periodically cleaned up via a separate process called vacuumlo. See managing large objects with the lo module for examples on managing large objects.
**Impact: Logical replication**
Large objects are not currently replicated in PostgreSQL during logical replication. To learn more, see the [Restrictions page in PostgreSQL documentation](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). In a [Blue/Green](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) configuration, this means large objects in the blue environment aren't replicated to the green environment.
**Impact: Major version upgrade**
An upgrade can run out of memory and fail if there are millions of large objects and the instance cannot handle them during an upgrade. The PostgreSQL major version upgrade process comprises of two broad phases: dumping the schema via pg\$1dump and restoring it through pg\$1restore. If your database has millions of large objects you need to ensure your instance has sufficient memory to handle the pg\$1dump and pg\$1restore during an upgrade and scale it to a larger instance type.
**General best practices:**
+ Regularly use the vacuumlo utility to remove any orphaned large objects you may have.
+ Consider using the BYTEA datatype for storing your large objects in the database.
**Approximate threshold:** [Millions](#PostgreSQL.HighObjectCount.Note)
## Approximate thresholds
The approximate thresholds mentioned in this topic are only used to provide an estimate of how far a particular resource can scale. They represent the general range where the described impacts become more likely, but actual behavior depends on your specific workload, instance size, and configuration. While it may be possible to exceed these estimates, care and maintenance must be adhered to so as to avoid the impacts listed.
# Improved memory management in Aurora PostgreSQL
Aurora PostgreSQL now includes advanced memory management capabilities to optimize database performance and resilience under varying workloads. These improvements help Aurora PostgreSQL maintain consistent availability and responsiveness, even during periods of high memory demand.
This feature is available and enabled by default in the following Aurora PostgreSQL versions for provisioned instances:
+ 15.3 and all higher minor versions
+ 14.8 and higher minor versions
+ 13.11 and higher minor versions
+ 12.15 and higher minor versions
+ 11.20 and higher minor versions
This feature is available and enabled by default in the following Aurora PostgreSQL for Aurora Serverless instances:
+ 16.3 and all higher minor versions
+ 15.7 and all higher minor versions
+ 14.12 and higher minor versions
+ 13.15 and higher minor versions
When customer workloads use up all available free memory, the operating system may restart the database to protect resources, leading to temporary unavailability. The new memory management improvements in Aurora PostgreSQL proactively cancel certain transactions when the system experiences high memory pressure, helping to maintain database stability.
The key features of improved memory management is as follows:
+ Cancelling database transactions that request more memory when the system is approaching critical memory pressure.
+ The system is said to be under critical memory pressure, when it exhausts all the physical memory and is about to exhaust the swap. In these circumstances, any transaction that requests memory will be cancelled in an effort to immediately reduce memory pressure in the DB instance.
+ Essential PostgreSQL launchers and background workers such as autovacuum workers are always protected.
## Handling memory management parameters
**To turn on memory management**
This feature is turned on by default. An error message is displayed when a transaction is cancelled due to insufficient memory as shown in the following example:
```
ERROR: out of memory Detail: Failed on request of size 16777216.
```
**To turn off memory management**
To turn off this feature, connect to the Aurora PostgreSQL DB cluster with psql and use the SET statement for the parameter values as mentioned below.
**Note**
We recommend that you keep memory management enabled. This helps prevent potential out-of-memory errors that may lead to workload-induced database restarts due to memory exhaustion.
The following table shows how to turn off the memory management feature for the different Aurora PostgreSQL versions:
| Aurora PostgreSQL versions | Parameter | Default | Command to turn off memory management at session level |
| --- | --- | --- | --- |
| 11.20, 11.21, 12.15, 12.16, 13.11, 13.12, 14.8, 14.9, 15.3, 15.4 | `rds.memory_allocation_guard` | `false` | `SET rds.memory_allocation_guard = true;` |
| 12.17, 13.13, 14.10, 15.5, and higher versions | `rds.enable_memory_management` | `true` | `SET rds.enable_memory_management = false;` |
**Note**
The `rds.memory_allocation_guard` parameter has been deprecated in Aurora PostgreSQL 12.17, 13.13, 14.10, 15.5, and higher versions.
Setting the values of these parameters in the DB cluster parameter group prevents the queries from being canceled. For more information about DB cluster parameter group, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).
## Limitation
+ This feature is not supported in db.t3.medium instance class.
# Fast failover with Amazon Aurora PostgreSQL
Following, you can learn how to make sure that failover occurs as fast as possible. To recover quickly after failover, you can use cluster cache management for your Aurora PostgreSQL DB cluster. For more information, see [Fast recovery after failover with cluster cache management for Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md).
Some of the steps that you can take to make failover perform fast include the following:
+ Set Transmission Control Protocol (TCP) keepalives with short time frames, to stop longer running queries before the read timeout expires if there's a failure.
+ Set timeouts for Java Domain Name System (DNS) caching aggressively. Doing this helps ensure the Aurora read-only endpoint can properly cycle through read-only nodes on later connection attempts.
+ Set the timeout variables used in the JDBC connection string as low as possible. Use separate connection objects for short- and long-running queries.
+ Use the read and write Aurora endpoints that are provided to connect to the cluster.
+ Use RDS API operations to test application response on server-side failures. Also, use a packet dropping tool to test application response for client-side failures.
+ Use the AWS JDBC Driver to take full advantage of the failover capabilities of Aurora PostgreSQL. For more information about the AWS JDBC Driver and complete instructions for using it, see the [Amazon Web Services (AWS) JDBC Driver GitHub repository](https://github.com/aws/aws-advanced-jdbc-wrapper).
These are covered in more detail following.
**Topics**
+ [Setting TCP keepalives parameters](#AuroraPostgreSQL.BestPractices.FastFailover.TCPKeepalives)
+ [Configuring your application for fast failover](#AuroraPostgreSQL.BestPractices.FastFailover.Configuring)
+ [Testing failover](#AuroraPostgreSQL.BestPracticesFastFailover.Testing)
+ [Fast failover example in Java](#AuroraPostgreSQL.BestPractices.FastFailover.Example)
## Setting TCP keepalives parameters
When you set up a TCP connection, a set of timers is associated with the connection. When the keepalive timer reaches zero, a keepalive probe packet is sent to the connection endpoint. If the probe receives a reply, you can assume that the connection is still up and running.
Turning on TCP keepalive parameters and setting them aggressively ensures that if your client can't connect to the database, any active connections are quickly closed. The application can then connect to a new endpoint.
Make sure to set the following TCP keepalive parameters:
+ `tcp_keepalives_idle` controls the time, in seconds, after which a keepalive packet is sent when no data has been sent by the socket. ACKs aren't considered data. We recommend the following setting:
`tcp_keepalives_idle = 1`
+ `tcp_keepalives_interval` controls the time, in seconds, between sending subsequent keepalive packets after the initial packet is sent. Set this time by using the `tcp_keepalives_idle` parameter. We recommend the following setting:
`tcp_keepalives_interval = 1`
+ `tcp_keepalives_count` is the number of unacknowledged keepalive probes that occur before the application is notified. We recommend the following setting:
`tcp_keepalives_count = 5`
These settings should notify the application within five seconds when the database stops responding. If keepalive packets are often dropped within the application's network, you can set a higher `tcp_keepalives_count` value. Doing this allows for more buffer in less reliable networks, although it increases the time that it takes to detect an actual failure.
**To set TCP keepalive parameters on Linux**
1. Test how to configure your TCP keepalive parameters.
We recommend doing so by using the command line with the following commands. This suggested configuration is system-wide. In other words, it also affects all other applications that create sockets with the `SO_KEEPALIVE` option on.
```
sudo sysctl net.ipv4.tcp_keepalive_time=1
sudo sysctl net.ipv4.tcp_keepalive_intvl=1
sudo sysctl net.ipv4.tcp_keepalive_probes=5
```
1. After you've found a configuration that works for your application, persist these settings by adding the following lines to `/etc/sysctl.conf`, including any changes you made:
```
tcp_keepalive_time = 1
tcp_keepalive_intvl = 1
tcp_keepalive_probes = 5
```
## Configuring your application for fast failover
Following, you can find a discussion of several configuration changes for Aurora PostgreSQL that you can make for fast failover. To learn more about PostgreSQL JDBC driver setup and configuration, see the [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/documentation/head/index.html) documentation.
**Topics**
+ [Reducing DNS cache timeouts](#AuroraPostgreSQL.BestPractices.FastFailover.Configuring.Timeouts)
+ [Setting an Aurora PostgreSQL connection string for fast failover](#AuroraPostgreSQL.BestPractices.FastFailover.Configuring.ConnectionString)
+ [Other options for obtaining the host string](#AuroraPostgreSQL.BestPractices.FastFailover.Configuring.HostString)
### Reducing DNS cache timeouts
When your application tries to establish a connection after a failover, the new Aurora PostgreSQL writer will be a previous reader. You can find it by using the Aurora read-only endpoint before DNS updates have fully propagated. Setting the java DNS time to live (TTL) to a low value, such as under 30 seconds, helps cycle between reader nodes on later connection attempts.
```
// Sets internal TTL to match the Aurora RO Endpoint TTL
java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
// If the lookup fails, default to something like small to retry
java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");
```
### Setting an Aurora PostgreSQL connection string for fast failover
To use Aurora PostgreSQL fast failover, make sure that your application's connection string has a list of hosts instead of just a single host. Following is an example connection string that you can use to connect to an Aurora PostgreSQL cluster. In this example, the hosts are in bold.
```
jdbc:postgresql://myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432
/postgres?user=&password=&loginTimeout=2
&connectTimeout=2&cancelSignalTimeout=2&socketTimeout=60
&tcpKeepAlive=true&targetServerType=primary
```
For best availability and to avoid a dependency on the RDS API, we recommend that you maintain a file to connect with. This file contains a host string that your application reads from when you establish a connection to the database. This host string has all the Aurora endpoints available for the cluster. For more information about Aurora endpoints, see [Amazon Aurora endpoint connections](Aurora.Overview.Endpoints.md).
For example, you might store your endpoints in a local file as shown following.
```
myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432
```
Your application reads from this file to populate the host section of the JDBC connection string. Renaming the DB cluster causes these endpoints to change. Make sure that your application handles this event if it occurs.
Another option is to use a list of DB instance nodes, as follows.
```
my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node3.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node4.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432
```
The benefit of this approach is that the PostgreSQL JDBC connection driver loops through all nodes on this list to find a valid connection. In contrast, when you use the Aurora endpoints only two nodes are tried in each connection attempt. However, there's a downside to using DB instance nodes. If you add or remove nodes from your cluster and the list of instance endpoints becomes stale, the connection driver might never find the correct host to connect to.
To help ensure that your application doesn't wait too long to connect to any one host, set the following parameters aggressively:
+ `targetServerType` – Controls whether the driver connects to a write or read node. To ensure that your applications reconnect only to a write node, set the `targetServerType` value to `primary`.
Values for the `targetServerType` parameter include `primary`, `secondary`, `any`, and `preferSecondary`. The `preferSecondary` value attempts to establish a connection to a reader first. It connects to the writer if no reader connection can be established.
+ `loginTimeout` – Controls how long your application waits to log in to the database after a socket connection has been established.
+ `connectTimeout` – Controls how long the socket waits to establish a connection to the database.
You can modify other application parameters to speed up the connection process, depending on how aggressive you want your application to be:
+ `cancelSignalTimeout` – In some applications, you might want to send a "best effort" cancel signal on a query that has timed out. If this cancel signal is in your failover path, consider setting it aggressively to avoid sending this signal to a dead host.
+ `socketTimeout` – This parameter controls how long the socket waits for read operations. This parameter can be used as a global "query timeout" to ensure no query waits longer than this value. A good practice is to have two connection handlers. One connection handler runs short-lived queries and sets this value lower. Another connection handler, for long-running queries, has this value set much higher. With this approach, you can rely on TCP keepalive parameters to stop long-running queries if the server goes down.
+ `tcpKeepAlive` – Turn on this parameter to ensure the TCP keepalive parameters that you set are respected.
+ `loadBalanceHosts` – When set to `true`, this parameter has the application connect to a random host chosen from a list of candidate hosts.
### Other options for obtaining the host string
You can get the host string from several sources, including the `aurora_replica_status` function and by using the Amazon RDS API.
In many cases, you need to determine who the writer of the cluster is or to find other reader nodes in the cluster. To do this, your application can connect to any DB instance in the DB cluster and query the `aurora_replica_status` function. You can use this function to reduce the amount of time it takes to find a host to connect to. However, in certain network failure scenarios the `aurora_replica_status` function might show out-of-date or incomplete information.
A good way to ensure that your application can find a node to connect to is to try to connect to the cluster writer endpoint and then the cluster reader endpoint. You do this until you can establish a readable connection. These endpoints don't change unless you rename your DB cluster. Thus, you can generally leave them as static members of your application or store them in a resource file that your application reads from.
After you establish a connection using one of these endpoints, you can get information about the rest of the cluster. To do this, call the `aurora_replica_status` function. For example, the following command retrieves information with `aurora_replica_status`.
```
postgres=> SELECT server_id, session_id, highest_lsn_rcvd, cur_replay_latency_in_usec, now(), last_update_timestamp
FROM aurora_replica_status();
server_id | session_id | highest_lsn_rcvd | cur_replay_latency_in_usec | now | last_update_timestamp
-----------+--------------------------------------+------------------+----------------------------+-------------------------------+------------------------
mynode-1 | 3e3c5044-02e2-11e7-b70d-95172646d6ca | 594221001 | 201421 | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00
mynode-2 | 1efdd188-02e4-11e7-becd-f12d7c88a28a | 594221001 | 201350 | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00
mynode-3 | MASTER_SESSION_ID | | | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00
(3 rows)
```
For example, the hosts section of your connection string might start with both the writer and reader cluster endpoints, as shown following.
```
myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432
```
In this scenario, your application attempts to establish a connection to any node type, primary or secondary. When your application is connected, a good practice is to first examine the read/write status of the node. To do this, query for the result of the command `SHOW transaction_read_only`.
If the return value of the query is `OFF`, then you successfully connected to the primary node. However, suppose that the return value is `ON` and your application requires a read/write connection. In this case, you can call the `aurora_replica_status` function to determine the `server_id` that has `session_id='MASTER_SESSION_ID'`. This function gives you the name of the primary node. You can use this with the `endpointPostfix` described following.
Make sure that you're aware when you connect to a replica that has stale data. When this happens, the `aurora_replica_status` function might show out-of-date information. You can set a threshold for staleness at the application level. To check this, you can look at the difference between the server time and the `last_update_timestamp` value. In general, your application should avoid flipping between two hosts due to conflicting information returned by the `aurora_replica_status` function. Your application should try all known hosts first instead of following the data returned by `aurora_replica_status`.
#### Listing instances using the DescribeDBClusters API operation, example in Java
You can programmatically find the list of instances by using the [AWS SDK for Java](https://aws.amazon.com/sdk-for-java/), specifically the [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) API operation.
Following is a small example of how you might do this in Java 8.
```
AmazonRDS client = AmazonRDSClientBuilder.defaultClient();
DescribeDBClustersRequest request = new DescribeDBClustersRequest()
.withDBClusterIdentifier(clusterName);
DescribeDBClustersResult result =
rdsClient.describeDBClusters(request);
DBCluster singleClusterResult = result.getDBClusters().get(0);
String pgJDBCEndpointStr =
singleClusterResult.getDBClusterMembers().stream()
.sorted(Comparator.comparing(DBClusterMember::getIsClusterWriter)
.reversed()) // This puts the writer at the front of the list
.map(m -> m.getDBInstanceIdentifier() + endpointPostfix + ":" + singleClusterResult.getPort()))
.collect(Collectors.joining(","));
```
Here, `pgJDBCEndpointStr` contains a formatted list of endpoints, as shown following.
```
my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432
```
The variable `endpointPostfix` can be a constant that your application sets. Or your application can get it by querying the `DescribeDBInstances` API operation for a single instance in your cluster. This value remains constant within an AWS Region and for an individual customer. So it saves an API call to simply keep this constant in a resource file that your application reads from. In the example preceding, it's set to the following.
```
.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com
```
For availability purposes, a good practice is to default to using the Aurora endpoints of your DB cluster if the API isn't responding or takes too long to respond. The endpoints are guaranteed to be up to date within the time it takes to update the DNS record. Updating the DNS record with an endpoint typically takes less than 30 seconds. You can store the endpoint in a resource file that your application consumes.
## Testing failover
In all cases you must have a DB cluster with two or more DB instances in it.
From the server side, certain API operations can cause an outage that can be used to test how your applications responds:
+ [FailoverDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) – This operation attempts to promote a new DB instance in your DB cluster to writer.
The following code example shows how you can use `failoverDBCluster` to cause an outage. For more details about setting up an Amazon RDS client, see [Using the AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/basics.html).
```
public void causeFailover() {
final AmazonRDS rdsClient = AmazonRDSClientBuilder.defaultClient();
FailoverDBClusterRequest request = new FailoverDBClusterRequest();
request.setDBClusterIdentifier("cluster-identifier");
rdsClient.failoverDBCluster(request);
}
```
+ [RebootDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html) – Failover isn't guaranteed with this API operation. It shuts down the database on the writer, however. You can use it to test how your application responds to connections dropping. The `ForceFailover` parameter doesn't apply for Aurora engines. Instead, use the `FailoverDBCluster` API operation.
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) – Modifying the `Port` parameter causes an outage when the nodes in the cluster begin listening on a new port. In general, your application can respond to this failure first by ensuring that only your application controls port changes. Also, ensure that it can appropriately update the endpoints it depends on. You can do this by having someone manually update the port when they make modifications at the API level. Or you can do this by using the RDS API in your application to determine if the port has changed.
+ [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) – Modifying the `DBInstanceClass` parameter causes an outage.
+ [DeleteDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBInstance.html) – Deleting the primary (writer) causes a new DB instance to be promoted to writer in your DB cluster.
From the application or client side, if you use Linux, you can test how the application responds to sudden packet drops. You can do this based on whether port, host, or if TCP keepalive packets are sent or received by using the iptables command.
## Fast failover example in Java
The following code example shows how an application might set up an Aurora PostgreSQL driver manager.
The application calls the `getConnection` function when it needs a connection. A call to `getConnection` can fail to find a valid host. An example is when no writer is found but the `targetServerType` parameter is set to `primary`. In this case, the calling application should simply retry calling the function.
To avoid pushing the retry behavior onto the application, you can wrap this retry call into a connection pooler. With most connection poolers, you can specify a JDBC connection string. So your application can call into `getJdbcConnectionString` and pass that to the connection pooler. Doing this means you can use faster failover with Aurora PostgreSQL.
```
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
import org.joda.time.Duration;
public class FastFailoverDriverManager {
private static Duration LOGIN_TIMEOUT = Duration.standardSeconds(2);
private static Duration CONNECT_TIMEOUT = Duration.standardSeconds(2);
private static Duration CANCEL_SIGNAL_TIMEOUT = Duration.standardSeconds(1);
private static Duration DEFAULT_SOCKET_TIMEOUT = Duration.standardSeconds(5);
public FastFailoverDriverManager() {
try {
Class.forName("org.postgresql.Driver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
/*
* RO endpoint has a TTL of 1s, we should honor that here. Setting this aggressively makes sure that when
* the PG JDBC driver creates a new connection, it will resolve a new different RO endpoint on subsequent attempts
* (assuming there is > 1 read node in your cluster)
*/
java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
// If the lookup fails, default to something like small to retry
java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");
}
public Connection getConnection(String targetServerType) throws SQLException {
return getConnection(targetServerType, DEFAULT_SOCKET_TIMEOUT);
}
public Connection getConnection(String targetServerType, Duration queryTimeout) throws SQLException {
Connection conn = DriverManager.getConnection(getJdbcConnectionString(targetServerType, queryTimeout));
/*
* A good practice is to set socket and statement timeout to be the same thing since both
* the client AND server will stop the query at the same time, leaving no running queries
* on the backend
*/
Statement st = conn.createStatement();
st.execute("set statement_timeout to " + queryTimeout.getMillis());
st.close();
return conn;
}
private static String urlFormat = "jdbc:postgresql://%s"
+ "/postgres"
+ "?user=%s"
+ "&password=%s"
+ "&loginTimeout=%d"
+ "&connectTimeout=%d"
+ "&cancelSignalTimeout=%d"
+ "&socketTimeout=%d"
+ "&targetServerType=%s"
+ "&tcpKeepAlive=true"
+ "&ssl=true"
+ "&loadBalanceHosts=true";
public String getJdbcConnectionString(String targetServerType, Duration queryTimeout) {
return String.format(urlFormat,
getFormattedEndpointList(getLocalEndpointList()),
CredentialManager.getUsername(),
CredentialManager.getPassword(),
LOGIN_TIMEOUT.getStandardSeconds(),
CONNECT_TIMEOUT.getStandardSeconds(),
CANCEL_SIGNAL_TIMEOUT.getStandardSeconds(),
queryTimeout.getStandardSeconds(),
targetServerType
);
}
private List getLocalEndpointList() {
/*
* As mentioned in the best practices doc, a good idea is to read a local resource file and parse the cluster endpoints.
* For illustration purposes, the endpoint list is hardcoded here
*/
List newEndpointList = new ArrayList<>();
newEndpointList.add("myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432");
newEndpointList.add("myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432");
return newEndpointList;
}
private static String getFormattedEndpointList(List endpoints) {
return IntStream.range(0, endpoints.size())
.mapToObj(i -> endpoints.get(i).toString())
.collect(Collectors.joining(","));
}
}
```
# Fast recovery after failover with cluster cache management for Aurora PostgreSQL
For fast recovery of the writer DB instance in your Aurora PostgreSQL clusters if there's a failover, use cluster cache management for Amazon Aurora PostgreSQL. Cluster cache management ensures that application performance is maintained if there's a failover.
In a typical failover situation, you might see a temporary but large performance degradation after failover. This degradation occurs because when the failover DB instance starts, the buffer cache is empty. An empty cache is also known as a *cold cache*. A cold cache degrades performance because the DB instance has to read from the slower disk, instead of taking advantage of values stored in the buffer cache.
With cluster cache management, you set a specific reader DB instance as the failover target. Cluster cache management ensures that the data in the designated reader's cache is kept synchronized with the data in the writer DB instance's cache. The designated reader's cache with prefilled values is known as a *warm cache*. If a failover occurs, the designated reader uses values in its warm cache immediately when it's promoted to the new writer DB instance. This approach provides your application much better recovery performance.
Cluster cache management requires that the designated reader instance have the same instance class type and size (`db.r5.2xlarge` or `db.r5.xlarge`, for example) as the writer. Keep this in mind when you create your Aurora PostgreSQL DB clusters so that your cluster can recover during a failover. For a listing of instance class types and sizes, see [Hardware specifications for DB instance classes for Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html#Concepts.DBInstanceClass.Summary).
**Note**
Cluster cache management isn't supported for Aurora PostgreSQL secondary DB cluster that are part of Aurora global databases. For primary clusters where this feature is supported, it's recommended that no workload should run on the designated tier-0 reader.
**Contents**
+ [Configuring cluster cache management](#AuroraPostgreSQL.cluster-cache-mgmt.Configure)
+ [Enabling cluster cache management](#AuroraPostgreSQL.cluster-cache-mgmt.Enable)
+ [Setting the promotion tier priority for the writer DB instance](#AuroraPostgreSQL.cluster-cache-mgmt.Writer)
+ [Setting the promotion tier priority for a reader DB instance](#AuroraPostgreSQL.cluster-cache-mgmt.Reader)
+ [Monitoring the buffer cache](#AuroraPostgreSQL.cluster-cache-mgmt.Monitoring)
+ [Troubleshooting CCM configuration](#AuroraPostgreSQL.cluster-cache-mgmt.Troubleshooting)
## Configuring cluster cache management
To configure cluster cache management, do the following processes in order.
**Topics**
+ [Enabling cluster cache management](#AuroraPostgreSQL.cluster-cache-mgmt.Enable)
+ [Setting the promotion tier priority for the writer DB instance](#AuroraPostgreSQL.cluster-cache-mgmt.Writer)
+ [Setting the promotion tier priority for a reader DB instance](#AuroraPostgreSQL.cluster-cache-mgmt.Reader)
**Note**
Allow at least 1 minute after completing these steps for cluster cache management to be fully operational.
### Enabling cluster cache management
To enable cluster cache management, take the steps described following.
#### Console
**To enable cluster cache management**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Parameter groups**.
1. In the list, choose the parameter group for your Aurora PostgreSQL DB cluster.
The DB cluster must use a parameter group other than the default, because you can't change values in a default parameter group.
1. For **Parameter group actions**, choose **Edit**.
1. Set the value of the `apg_ccm_enabled` cluster parameter to **1**.
1. Choose **Save changes**.
#### AWS CLI
To enable cluster cache management for an Aurora PostgreSQL DB cluster, use the AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) command with the following required parameters:
+ `--db-cluster-parameter-group-name`
+ `--parameters`
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name my-db-cluster-parameter-group \
--parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
```
For Windows:
```
aws rds modify-db-cluster-parameter-group ^
--db-cluster-parameter-group-name my-db-cluster-parameter-group ^
--parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"
```
### Setting the promotion tier priority for the writer DB instance
For cluster cache management, make sure that the promotion priority is **tier-0** for the writer DB instance of the Aurora PostgreSQL DB cluster. The *promotion tier priority* is a value that specifies the order in which an Aurora reader is promoted to the writer DB instance after a failure. Valid values are 0–15, where 0 is the first priority and 15 is the last priority. For more information about the promotion tier, see [Fault tolerance for an Aurora DB cluster](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance).
#### Console
**To set the promotion priority for the writer DB instance to tier-0**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the **Writer** DB instance of the Aurora PostgreSQL DB cluster.
1. Choose **Modify**. The **Modify DB Instance** page appears.
1. On the **Additional configuration** panel, choose **tier-0** for the **Failover priority**.
1. Choose **Continue** and check the summary of modifications.
1. To apply the changes immediately after you save them, choose **Apply immediately**.
1. Choose **Modify DB Instance** to save your changes.
#### AWS CLI
To set the promotion tier priority to 0 for the writer DB instance using the AWS CLI, call the [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) command with the following required parameters:
+ `--db-instance-identifier`
+ `--promotion-tier`
+ `--apply-immediately`
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier writer-db-instance \
--promotion-tier 0 \
--apply-immediately
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier writer-db-instance ^
---promotion-tier 0 ^
--apply-immediately
```
### Setting the promotion tier priority for a reader DB instance
You must set only one reader DB instance for cluster cache management. To do so, choose a reader from the Aurora PostgreSQL cluster that is the same instance class and size as the writer DB instance. For example, if the writer uses `db.r5.xlarge`, choose a reader that uses this same instance class type and size. Then set its promotion tier priority to 0.
The *promotion tier priority *is a value that specifies the order in which an Aurora reader is promoted to the writer DB instance after a failure. Valid values are 0–15, where 0 is the first priority and 15 is the last priority.
#### Console
**To set the promotion priority of the reader DB instance to tier-0**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose a **Reader** DB instance of the Aurora PostgreSQL DB cluster that is the same instance class as the writer DB instance.
1. Choose **Modify**. The **Modify DB Instance** page appears.
1. On the **Additional configuration** panel, choose **tier-0** for the **Failover priority**.
1. Choose **Continue** and check the summary of modifications.
1. To apply the changes immediately after you save them, choose **Apply immediately**.
1. Choose **Modify DB Instance** to save your changes.
#### AWS CLI
To set the promotion tier priority to 0 for the reader DB instance using the AWS CLI, call the [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) command with the following required parameters:
+ `--db-instance-identifier`
+ `--promotion-tier`
+ `--apply-immediately`
**Example**
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--db-instance-identifier reader-db-instance \
--promotion-tier 0 \
--apply-immediately
```
For Windows:
```
aws rds modify-db-instance ^
--db-instance-identifier reader-db-instance ^
---promotion-tier 0 ^
--apply-immediately
```
## Monitoring the buffer cache
After setting up cluster cache management, you can monitor the state of synchronization between the writer DB instance's buffer cache and the designated reader's warm buffer cache. To examine the buffer cache contents on both the writer DB instance and the designated reader DB instance, use the PostgreSQL `pg_buffercache` module. For more information, see the [PostgreSQL `pg_buffercache` documentation](https://www.postgresql.org/docs/current/pgbuffercache.html).
**Using the `aurora_ccm_status` Function**
Cluster cache management also provides the `aurora_ccm_status` function. Use the `aurora_ccm_status` function on the writer DB instance to get the following information about the progress of cache warming on the designated reader:
+ `buffers_sent_last_minute` – How many buffers have been sent to the designated reader in the last minute.
+ `buffers_found_last_minute` – The number of frequently accessed buffers identified during the past minute.
+ `buffers_sent_last_scan` – How many buffers have been sent to the designated reader during the last complete scan of the buffer cache.
+ `buffers_found_last_scan` – How many buffers have been identified as frequently accessed and needed to be sent during the last complete scan of the buffer cache. Buffers already cached on the designated reader aren't sent.
+ `buffers_sent_current_scan` – How many buffers have been sent so far during the current scan.
+ `buffers_found_current_scan` – How many buffers have been identified as frequently accessed in the current scan.
+ `current_scan_progress` – How many buffers have been visited so far during the current scan.
The following example shows how to use the `aurora_ccm_status` function to convert some of its output into a warm rate and warm percentage.
```
SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps,
100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent
FROM aurora_ccm_status();
```
## Troubleshooting CCM configuration
When you enable `apg_ccm_enabled` cluster parameter, cluster cache management is automatically turned on at the instance level on the writer DB instance and one reader DB instance on the Aurora PostgreSQL DB cluster. The writer and reader instance should use the same instance class type and size. Their promotion tier priority is set to `0`. Other reader instances in the DB cluster should have a non-zero promotion tier and cluster cache management is disabled for those instances.
The following reasons may lead to issues in the configuration and disable cluster cache management:
+ When there is no single reader DB instance set to promotion tier 0.
+ When the writer DB instance is not set to promotion tier 0.
+ When more than one reader DB instances are set to promotion tier 0.
+ When the writer and one reader DB instances with promotion tier 0 doesn't have the same instance size.
# Managing Aurora PostgreSQL connection churn with pooling
When client applications connect and disconnect so often that Aurora PostgreSQL DB cluster response time slows, the cluster is said to be experiencing *connection churn*. Each new connection to the Aurora PostgreSQL DB cluster endpoint consumes resources, thus reducing the resources that can be used to process the actual workload. Connection churn is an issue that we recommend that you manage by following some of the best practices discussed following.
For starters, you can improve response times on Aurora PostgreSQL DB clusters that have high rates of connection churn. To do this, you can use a connection pooler, such as RDS Proxy. A *connection pooler* provides a cache of ready to use connections for clients. Almost all versions of Aurora PostgreSQL support RDS Proxy. For more information, see [Amazon RDS Proxy with Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.apg).
If your specific version of Aurora PostgreSQL doesn't support RDS Proxy, you can use another PostgreSQL–compatible connection pooler, such as PgBouncer. To learn more, see the [PgBouncer](https://www.pgbouncer.org/) website.
To see if your Aurora PostgreSQL DB cluster can benefit from connection pooling, you can check the `postgresql.log` file for connections and disconnections. You can also use Performance Insights to find out how much connection churn your Aurora PostgreSQL DB cluster is experiencing. Following, you can find information about both topics.
## Logging connections and disconnections
The PostgreSQL `log_connections` and `log_disconnections` parameters can capture connections and disconnections to the writer instance of the Aurora PostgreSQL DB cluster. By default, these parameters are turned off. To turn these parameters on, use a custom parameter group and turn on by changing the value to 1. For more information about custom parameter groups, see [DB cluster parameter groups for Amazon Aurora DB clusters](USER_WorkingWithDBClusterParamGroups.md). To check the settings, connect to your DB cluster endpoint for Aurora PostgreSQL by using psql and query as follows.
```
labdb=> SELECT setting FROM pg_settings
WHERE name = 'log_connections';
setting
---------
on
(1 row)
labdb=> SELECT setting FROM pg_settings
WHERE name = 'log_disconnections';
setting
---------
on
(1 row)
```
With both of these parameters turned on, the log captures all new connections and disconnections. You see the user and database for each new authorized connection. At disconnection time, the session duration is also logged, as shown in the following example.
```
2022-03-07 21:44:53.978 UTC [16641] LOG: connection authorized: user=labtek database=labdb application_name=psql
2022-03-07 21:44:55.718 UTC [16641] LOG: disconnection: session time: 0:00:01.740 user=labtek database=labdb host=[local]
```
To check your application for connection churn, turn on these parameters if they're not on already. Then gather data in the PostgreSQL log for analysis by running your application with a realistic workload and time period. You can view the log file in the RDS console. Choose the writer instance of your Aurora PostgreSQL DB cluster, and then choose the **Logs & events** tab. For more information, see [Viewing and listing database log files](USER_LogAccess.Procedural.Viewing.md).
Or you can download the log file from the console and use the following command sequence. This sequence finds the total number of connections authorized and dropped per minute.
```
grep "connection authorized\|disconnection: session time:" postgresql.log.2022-03-21-16|\
awk {'print $1,$2}' |\
sort |\
uniq -c |\
sort -n -k1
```
In the example output, you can see a spike in authorized connections followed by disconnections starting at 16:12:10.
```
.....
,......
.........
5 2022-03-21 16:11:55 connection authorized:
9 2022-03-21 16:11:55 disconnection: session
5 2022-03-21 16:11:56 connection authorized:
5 2022-03-21 16:11:57 connection authorized:
5 2022-03-21 16:11:57 disconnection: session
32 2022-03-21 16:12:10 connection authorized:
30 2022-03-21 16:12:10 disconnection: session
31 2022-03-21 16:12:11 connection authorized:
27 2022-03-21 16:12:11 disconnection: session
27 2022-03-21 16:12:12 connection authorized:
27 2022-03-21 16:12:12 disconnection: session
41 2022-03-21 16:12:13 connection authorized:
47 2022-03-21 16:12:13 disconnection: session
46 2022-03-21 16:12:14 connection authorized:
41 2022-03-21 16:12:14 disconnection: session
24 2022-03-21 16:12:15 connection authorized:
29 2022-03-21 16:12:15 disconnection: session
28 2022-03-21 16:12:16 connection authorized:
24 2022-03-21 16:12:16 disconnection: session
40 2022-03-21 16:12:17 connection authorized:
42 2022-03-21 16:12:17 disconnection: session
40 2022-03-21 16:12:18 connection authorized:
40 2022-03-21 16:12:18 disconnection: session
.....
,......
.........
1 2022-03-21 16:14:10 connection authorized:
1 2022-03-21 16:14:10 disconnection: session
1 2022-03-21 16:15:00 connection authorized:
1 2022-03-21 16:16:00 connection authorized:
```
With this information, you can decide if your workload can benefit from a connection pooler. For more detailed analysis, you can use Performance Insights.
## Detecting connection churn with Performance Insights
You can use Performance Insights to assess the amount of connection churn on your Aurora PostgreSQL-Compatible Edition DB cluster. When you create an Aurora PostgreSQL DB cluster, the setting for Performance Insights is turned on by default. If you cleared this choice when you created your DB cluster, modify your cluster to turn on the feature. For more information, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md).
With Performance Insights running on your Aurora PostgreSQL DB cluster, you can choose the metrics that you want to monitor. You can access Performance Insights from the navigation pane in the console. You can also access Performance Insights from the **Monitoring** tab of the writer instance for your Aurora PostgreSQL DB cluster, as shown in the following image.
![\[Image of accessing Performance Insights from within the RDS console and selected Aurora PostgreSQL DB cluster.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_pooling_PI_1.png)
From the Performance Insights console, choose **Manage metrics**. To analyze your Aurora PostgreSQL DB cluster's connection and disconnection activity, choose the following metrics. These are all metrics from PostgreSQL.
+ `xact_commit` – The number of committed transactions.
+ `total_auth_attempts` – The number of attempted authenticated user connections per minute.
+ `numbackends` – The number of backends currently connected to the database.
![\[Image of accessing Performance Insights from within the RDS console and selected Aurora PostgreSQL DB cluster.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_churn_PI_4.png)
To save the settings and display connection activity, choose **Update graph**.
In the following image, you can see the impact of running pgbench with 100 users. The line showing connections is on a consistent upward slope. To learn more about pgbench and how to use it, see [pgbench](https://www.postgresql.org/docs/current/pgbench.html) in PostgreSQL documentation.
![\[Image of Performance Insights showing need for connection pooling.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_pooling_PI_2.png)
The image shows that running a workload with as few as 100 users without a connection pooler can cause a significant increase in the number of `total_auth_attempts` throughout the duration of workload processing. Note that it's best to keep `total_auth_attempts` as close to zero as possible.
With RDS Proxy connection pooling, the connection attempts increase at the start of the workload. After setting up the connection pool, the average declines. The resources used by transactions and backend use stays consistent throughout workload processing.
![\[Image of Performance Insights showing benefit of RDS Proxy for connection pooling.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_pooling_PI_3.png)
For more information about using Performance Insights with your Aurora PostgreSQL DB cluster, see [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md). To analyze the metrics, see [Analyzing metrics with the Performance Insights dashboard](USER_PerfInsights.UsingDashboard.md).
## Demonstrating the benefits of connection pooling
As mentioned previously, if you determine that your Aurora PostgreSQL DB cluster has a connection churn problem, you can use RDS Proxy for improved performance. Following, you can find an example that shows the differences in processing a workload when connections are pooled and when they're not. The example uses pgbench to model a transaction workload.
As is psql, pgbench is a PostgreSQL client application that you can install and run from your local client machine. You can also install and run it from the Amazon EC2 instance that you use for managing your Aurora PostgreSQL DB cluster. For more information, see [pgbench](https://www.postgresql.org/docs/current/pgbench.html) in the PostgreSQL documentation.
To step through this example, you first create the pgbench environment in your database. The following command is the basic template for initializing the pgbench tables in the specified database. This example uses the default main user account, `postgres`, for the login. Change it as needed for your Aurora PostgreSQL DB cluster. You create the pgbench environment in a database on the writer instance of your cluster.
**Note**
The pgbench initialization process drops and recreates tables named `pgbench_accounts`, `pgbench_branches`, `pgbench_history`, and `pgbench_tellers`. Be sure that the database that you choose for `dbname` when you initialize pgbench doesn't use these names.
```
pgbench -U postgres -h db-cluster-instance-1.111122223333.aws-region.rds.amazonaws.com -p 5432 -d -i -s 50 dbname
```
For pgbench, specify the following parameters.
**-d**
Outputs a debugging report as pgbench runs.
**-h**
Specifies the endpoint of the Aurora PostgreSQL DB cluster's writer instance.
**-i**
Initializes the pgbench environment in the database for the benchmark tests.
**-p**
Identifies the port used for database connections. The default for Aurora PostgreSQL is typically 5432 or 5433.
**-s**
Specifies the scaling factor to use for populating the tables with rows. The default scaling factor is 1, which generates 1 row in the `pgbench_branches` table, 10 rows in the `pgbench_tellers` table, and 100000 rows in the `pgbench_accounts` table.
**-U**
Specifies the user account for the Aurora PostgreSQL DB cluster's writer instance.
After the pgbench environment is set up, you can then run benchmarking tests with and without connection pooling. The default test consists of a series of five SELECT, UPDATE, and INSERT commands per transaction that run repeatedly for the time specified. You can specify scaling factor, number of clients, and other details to model your own use cases.
As an example, the command that follows runs the benchmark for 60 seconds (-T option, for time) with 20 concurrent connections (the -c option). The -C option makes the test run using a new connection each time, rather than once per client session. This setting gives you an indication of the connection overhead.
```
pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 -C labdb
Password:**********
pgbench (14.3, server 13.3)
starting vacuum...end.
transaction type:
scaling factor: 50
query mode: simple
number of clients: 20
number of threads: 1
duration: 60 s
number of transactions actually processed: 495
latency average = 2430.798 ms
average connection time = 120.330 ms
tps = 8.227750 (including reconnection times)
```
Running pgbench on the writer instance of an Aurora PostgreSQL DB cluster without reusing connections shows that only about 8 transactions are processed each second. This gives a total of 495 transactions during the 1-minute test.
If you reuse connections, the response from Aurora PostgreSQL DB cluster for the number of users is almost 20 times faster. With reuse, a total of 9,042 transactions is processed compared to 495 in the same amount of time and for the same number of user connections. The difference is that in the following, each connection is being reused.
```
pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 labdb
Password:*********
pgbench (14.3, server 13.3)
starting vacuum...end.
transaction type:
scaling factor: 50
query mode: simple
number of clients: 20
number of threads: 1
duration: 60 s
number of transactions actually processed: 9042
latency average = 127.880 ms
initial connection time = 2311.188 ms
tps = 156.396765 (without initial connection time)
```
This example shows you that pooling connections can significantly improve response times. For information about setting up RDS Proxy for your Aurora PostgreSQL DB cluster, see [Amazon RDS Proxyfor Aurora](rds-proxy.md).
# Dead connection handling in PostgreSQL
Dead connections occur when a database session remains active on the server despite the client application having abandoned or terminated abnormally. This situation typically arises when client processes crash or terminate unexpectedly without properly closing their database connections or canceling ongoing requests.
PostgreSQL efficiently identifies and cleans up dead connections when server processes are idle or attempt to send data to clients. However, detection is challenging for sessions that are idle, waiting for client input, or actively running queries. To handle these scenarios, PostgreSQL provides `tcp_keepalives_*`, `tcp_user_timeout`, and `client_connection_check_interval` parameters.
**Topics**
+ [Understanding TCP keepalive](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [Key TCP keepalive parameters in Aurora PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [Use cases for TCP keepalive settings](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [Best practices](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Understanding TCP keepalive
TCP Keepalive is a protocol-level mechanism that helps maintain and verify connection integrity. Each TCP connection maintains kernel-level settings that govern keepalive behavior. When the keepalive timer expires, the system does the following:
+ Sends a probe packet with no data and the ACK flag set.
+ Expects a response from the remote endpoint according to TCP/IP specifications.
+ Manages connection state based on the response or lack thereof.
## Key TCP keepalive parameters in Aurora PostgreSQL
| Parameter | Description | Default values |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Specifies number of seconds of inactivity before sending keepalive message. | 300 |
| tcp\$1keepalives\$1interval | Specifies number of seconds between retransmissions of unacknowledged keepalive messages. | 30 |
| tcp\$1keepalives\$1count | Maximum lost keepalive messages before declaring connection dead | 2 |
| tcp\$1user\$1timeout | Specifies how long (in Milliseconds) unacknowledged data can remain before forcibly closing the connection. | 0 |
| client\$1connection\$1check\$1interval | Sets the interval (in Milliseconds) for checking client connection status during long-running queries. This ensures quicker detection of closed connections. | 0 |
## Use cases for TCP keepalive settings
### Keeping idle sessions alive
To prevent idle connections from being terminated by firewalls or routers due to inactivity:
+ Configure `tcp_keepalives_idle` to send keepalive packets at regular intervals.
### Detecting dead connections
To detect dead connections promptly:
+ Adjust `tcp_keepalives_idle`, `tcp_keepalives_interval`, and `tcp_keepalives_count`. For example, with Aurora PostgreSQL defaults, it takes about a minute (2 probes × 30 seconds) to detect a dead connection. Lowering these values can speed up detection.
+ Use `tcp_user_timeout` to specify the maximum wait time for an acknowledgment.
TCP keepalive settings help the kernel detect dead connections, but PostgreSQL may not act until the socket is used. If a session is running a long query, dead connections might only be detected after query completion. In PostgreSQL 14 and higher versions, `client_connection_check_interval` can expedite dead connection detection by periodically polling the socket during query execution.
## Best practices
+ **Set reasonable keepalive intervals:** Tune `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` and `tcp_keepalives_interval` to balance detection speed and resource use.
+ **Optimize for your environment:** Align settings with network behavior, firewall policies, and session needs.
+ **Leverage PostgreSQL features:** Use `client_connection_check_interval` in PostgreSQL 14 and higher versions for efficient connection checks.
# Tuning memory parameters for Aurora PostgreSQL
In Amazon Aurora PostgreSQL, you can use several parameters that control the amount of memory used for various processing tasks. If a task takes more memory than the amount set for a given parameter, Aurora PostgreSQL uses other resources for processing, such as by writing to disk. This can cause your Aurora PostgreSQL DB cluster to slow or potentially halt, with an out-of-memory error.
The default setting for each memory parameter can usually handle its intended processing tasks. However, you can also tune your Aurora PostgreSQL DB cluster's memory-related parameters. You do this tuning to ensure that enough memory is allocated for processing your specific workload.
Following, you can find information about parameters that control memory management. You can also learn how to assess memory utilization.
## Checking and setting parameter values
The parameters that you can set to manage memory and assess your Aurora PostgreSQL DB cluster's memory usage include the following:
+ `work_mem` – Specifies the amount of memory that the Aurora PostgreSQL DB cluster uses for internal sort operations and hash tables before it writes to temporary disk files.
+ `log_temp_files` – Logs temporary file creation, file names, and sizes. When this parameter is turned on, a log entry is stored for each temporary file that gets created. Turn this on to see how frequently your Aurora PostgreSQL DB cluster needs to write to disk. Turn it off again after you've gathered information about your Aurora PostgreSQL DB cluster's temporary file generation, to avoid excessive logging.
+ `logical_decoding_work_mem` – Specifies the amount of memory (in kilobytes) to be used by each internal reorder buffer before spilling to disk. This memory is used for *Logical decoding*, which is the process to create a replica. It is done by converting data from the write-ahead log (WAL) file to the logical streaming output needed by the target.
The value of this parameter creates a single buffer of the size specified for each replication connection. By default, it's 65536 KB. After this buffer is filled, the excess is written to disk as a file. To minimize disk activity, you can set the value of this parameter to a much higher value than that of `work_mem`.
These are all dynamic parameters, so you can change them for the current session. To do this, connect to the Aurora PostgreSQL DB cluster with psql and using the `SET` statement, as shown following.
```
SET parameter_name TO parameter_value;
```
Session settings last for the duration of the session only. When the session ends, the parameter reverts to its setting in the DB cluster parameter group. Before changing any parameters, first check the current values by querying the `pg_settings` table, as follows.
```
SELECT unit, setting, max_val
FROM pg_settings WHERE name='parameter_name';
```
For example, to find the value of the `work_mem` parameter, connect to the Aurora PostgreSQL DB cluster's writer instance and run the following query.
```
SELECT unit, setting, max_val, pg_size_pretty(max_val::numeric)
FROM pg_settings WHERE name='work_mem';
unit | setting | max_val | pg_size_pretty
------+----------+-----------+----------------
kB | 1024 | 2147483647| 2048 MB
(1 row)
```
Changing parameter settings so that they persist requires using a custom DB cluster parameter group. After exercising your Aurora PostgreSQL DB cluster with different values for these parameters using the `SET` statement, you can create a custom parameter group and apply to your Aurora PostgreSQL DB cluster. For more information, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).
## Understanding the working memory parameter
The working memory parameter (`work_mem`) specifies the maximum amount of memory that Aurora PostgreSQL can use to process complex queries. Complex queries include those that involve sorting or grouping operations—in other words, queries that use the following clauses:
+ ORDER BY
+ DISTINCT
+ GROUP BY
+ JOIN (MERGE and HASH)
The query planner indirectly affects how your Aurora PostgreSQL DB cluster uses working memory. The query planner generates execution plans for processing SQL statements. A given plan might break up a complex query into multiple units of work that can be run in parallel. When possible, Aurora PostgreSQL uses the amount of memory specified in the `work_mem` parameter for each session before writing to disk for each parallel process.
Multiple database users running multiple operations concurrently and generating multiple units of work in parallel can exhaust your Aurora PostgreSQL DB cluster's allocated working memory. This can lead to excessive temporary file creation and disk I/O, or worse, it can lead to an out-of-memory error.
### Identifying temporary file use
Whenever the memory required to process queries exceeds the value specified in the `work_mem` parameter, the working data is offloaded to disk in a temporary file. You can see how often this occurs by turning on the `log_temp_files` parameter. By default, this parameter is off (it's set to -1). To capture all temporary file information, set this parameter to 0. Set `log_temp_files` to any other positive integer to capture temporary file information for files equal to or greater than that amount of data (in kilobytes). In the following image, you can see an example from AWS Management Console.
![\[Image of custom parameter group with log_temp_files set to 1024kB.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/postgres_tuning_custom_parameter.png)
After configuring temporary file logging, you can test with your own workload to see if your working memory setting is sufficient. You can also simulate a workload by using pgbench, a simple benchmarking application from the PostgreSQL community.
The following example initializes (`-i`) `pgbench` by creating the necessary tables and rows for running the tests. In this example, the scaling factor (`-s` 50) creates 50 rows in the `pgbench_branches` table, 500 rows in `pgbench_tellers`, and 5,000,000 rows in the `pgbench_accounts` table in the `labdb` database.
```
pgbench -U postgres -h your-cluster-instance-1.111122223333.aws-regionrds.amazonaws.com -p 5432 -i -s 50 labdb
Password:
dropping old tables...
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
creating tables...
generating data (client-side)...
5000000 of 5000000 tuples (100%) done (elapsed 15.46 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 61.13 s (drop tables 0.08 s, create tables 0.39 s, client-side generate 54.85 s, vacuum 2.30 s, primary keys 3.51 s)
```
After initializing the environment, you can run the benchmark for a specific time (`-T`) and the number of clients (`-c`). This example also uses the `-d` option to output debugging information as the transactions are processed by the Aurora PostgreSQL DB cluster.
```
pgbench -h -U postgres your-cluster-instance-1.111122223333.aws-regionrds.amazonaws.com -p 5432 -d -T 60 -c 10 labdb
Password:*******
pgbench (14.3)
starting vacuum...end.
transaction type:
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 1
duration: 60 s
number of transactions actually processed: 1408
latency average = 398.467 ms
initial connection time = 4280.846 ms
tps = 25.096201 (without initial connection time)
```
For more information about pgbench, see [pgbench](https://www.postgresql.org/docs/current/pgbench.html) in the PostgreSQL documentation.
You can use the psql metacommand command (`\d`) to list the relations such as tables, views, and indexes created by pgbench.
```
labdb=> \d pgbench_accounts
Table "public.pgbench_accounts"
Column | Type | Collation | Nullable | Default
----------+---------------+-----------+----------+---------
aid | integer | | not null |
bid | integer | | |
abalance | integer | | |
filler | character(84) | | |
Indexes:
"pgbench_accounts_pkey" PRIMARY KEY, btree (aid)
```
As shown in the output, the `pgbench_accounts` table is indexed on the `aid` column. To ensure that this next query uses working memory, query any nonindexed column, such as that shown in the following example.
```
postgres=> SELECT * FROM pgbench_accounts ORDER BY bid;
```
Check the log for the temporary files. To do so, open the AWS Management Console, choose the Aurora PostgreSQL DB cluster instance, and then choose the **Logs & Events** tab. View the logs in the console or download for further analysis. As shown in the following image, the size of the temporary files needed to process the query indicates that you should consider increasing the amount specified for the `work_mem` parameter.
![\[Image of the log file from AWS Management Console showing the temporary files.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/postgres_tuning_log_temp_files.png)
You can configure this parameter differently for individuals and groups, based on your operational needs. For example, you can set the `work_mem` parameter to 8 GB for the role named `dev_team`.
```
postgres=> ALTER ROLE dev_team SET work_mem=‘8GB';
```
With this setting for `work_mem`, any role that's a member of the `dev_team` role is allotted up to 8 GB of working memory.
## Using indexes for faster response time
If your queries are taking too long to return results, you can verify that your indexes are being used as expected. First, turn on `\timing`, the psql metacommand, as follows.
```
postgres=> \timing on
```
After turning on timing, use a simple SELECT statement.
```
postgres=> SELECT COUNT(*) FROM
(SELECT * FROM pgbench_accounts
ORDER BY bid)
AS accounts;
count
-------
5000000
(1 row)
Time: 3119.049 ms (00:03.119)
```
As shown in the output, this query took just over 3 seconds to complete. To improve the response time, create an index on `pgbench_accounts`, as follows.
```
postgres=> CREATE INDEX ON pgbench_accounts(bid);
CREATE INDEX
```
Rerun the query, and notice the faster response time. In this example, the query completed about 5 times faster, in about half a second.
```
postgres=> SELECT COUNT(*) FROM (SELECT * FROM pgbench_accounts ORDER BY bid) AS accounts;
count
-------
5000000
(1 row)
Time: 567.095 ms
```
## Adjusting working memory for logical decoding
Logical replication has been available in all versions of Aurora PostgreSQL since its introduction in PostgreSQL version 10. When you configure logical replication, you can also set the `logical_decoding_work_mem` parameter to specify the amount of memory that the logical decoding process can use for the decoding and streaming process.
During logical decoding, write-ahead log (WAL) records are converted to SQL statements that are then sent to another target for logical replication or another task. When a transaction is written to the WAL and then converted, the entire transaction must fit into the value specified for `logical_decoding_work_mem`. By default, this parameter is set to 65536 KB. Any overflow is written to disk. This means that it must be reread from the disk before it can be sent to its destination, thus slowing the overall process.
You can assess the amount of transaction overflow in your current workload at a specific point in time by using the `aurora_stat_file` function as shown in the following example.
```
SELECT split_part (filename, '/', 2)
AS slot_name, count(1) AS num_spill_files,
sum(used_bytes) AS slot_total_bytes,
pg_size_pretty(sum(used_bytes)) AS slot_total_size
FROM aurora_stat_file()
WHERE filename like '%spill%'
GROUP BY 1;
slot_name | num_spill_files | slot_total_bytes | slot_total_size
------------+-----------------+------------------+-----------------
slot_name | 590 | 411600000 | 393 MB
(1 row)
```
This query returns the count and size of spill files on your Aurora PostgreSQL DB cluster when the query is invoked. Longer running workloads might not have any spill files on disk yet. To profile long-running workloads, we recommend that you create a table to capture the spill file information as the workload runs. You can create the table as follows.
```
CREATE TABLE spill_file_tracking AS
SELECT now() AS spill_time,*
FROM aurora_stat_file()
WHERE filename LIKE '%spill%';
```
To see how spill files are used during logical replication, set up a publisher and subscriber and then start a simple replication. For more information, see [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md). With replication under way, you can create a job that captures the result set from the `aurora_stat_file()` spill file function, as follows.
```
INSERT INTO spill_file_tracking
SELECT now(),*
FROM aurora_stat_file()
WHERE filename LIKE '%spill%';
```
Use the following psql command to run the job once per second.
```
\watch 0.5
```
As the job is running, connect to the writer instance from another psql session. Use the following series of statements to run a workload that exceeds the memory configuration and causes Aurora PostgreSQL to create a spill file.
```
labdb=> CREATE TABLE my_table (a int PRIMARY KEY, b int);
CREATE TABLE
labdb=> INSERT INTO my_table SELECT x,x FROM generate_series(0,10000000) x;
INSERT 0 10000001
labdb=> UPDATE my_table SET b=b+1;
UPDATE 10000001
```
These statements take several minutes to complete. When finished, press the Ctrl key and the C key together to stop the monitoring function. Then use the following command to create a table to hold the information about the Aurora PostgreSQL DB cluster's spill file usage.
```
SELECT spill_time, split_part (filename, '/', 2)
AS slot_name, count(1)
AS spills, sum(used_bytes)
AS slot_total_bytes, pg_size_pretty(sum(used_bytes))
AS slot_total_size FROM spill_file_tracking
GROUP BY 1,2 ORDER BY 1;
spill_time | slot_name | spills | slot_total_bytes | slot_total_size
------------------------------+-----------------------+--------+------------------+-----------------
2022-04-15 13:42:52.528272+00 | replication_slot_name | 1 | 142352280 | 136 MB
2022-04-15 14:11:33.962216+00 | replication_slot_name | 4 | 467637996 | 446 MB
2022-04-15 14:12:00.997636+00 | replication_slot_name | 4 | 569409176 | 543 MB
2022-04-15 14:12:03.030245+00 | replication_slot_name | 4 | 569409176 | 543 MB
2022-04-15 14:12:05.059761+00 | replication_slot_name | 5 | 618410996 | 590 MB
2022-04-15 14:12:07.22905+00 | replication_slot_name | 5 | 640585316 | 611 MB
(6 rows)
```
The output shows that running the example created five spill files that used 611 MB of memory. To avoid writing to disk, we recommend setting the `logical_decoding_work_mem` parameter to the next highest memory size, 1024.
# Using Amazon CloudWatch metrics to analyze resource usage for Aurora PostgreSQL
Aurora automatically sends metric data to CloudWatch in 1-minute periods. You can analyze resource usage for Aurora PostgreSQL using CloudWatch metrics. You can evaluate the network throughput and the network usage with the metrics.
## Evaluating network throughput with CloudWatch
When your system usage approaches the resource limits for your instance type, the processing can slow down. You can use CloudWatch **Logs Insights** to monitor your storage resource usage and ensure that sufficient resources are available. When needed, you can modify the DB instance to a larger instance class.
Aurora storage processing may be slow because of:
+ Insufficient network bandwidth between the client and DB instance.
+ Insufficient network bandwidth to the storage subsystem.
+ A workload that is large for your instance type.
You can query CloudWatch **Logs Insights** to generate a graph of Aurora storage resource usage to monitor the resources. The graph shows the CPU utilization and metrics to help you decide whether to scale up to a larger instance size. For information about the query syntax for CloudWatch **Logs Insights**, see [CloudWatch Logs Insights query syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)
To use CloudWatch, you need to export your Aurora PostgreSQL log files to CloudWatch. You can also modify your existing cluster to export logs to CloudWatch. For information about exporting logs to CloudWatch, see [Turning on the option to publish logs to Amazon CloudWatch](AuroraPostgreSQL.CloudWatch.Publishing.md).
You need the **Resource ID** of your DB instance to query the CloudWatch **Logs Insights**. The **Resource ID** is available in the **Configuration** tab in your console:
![\[Resource ID in the Configuration tab of your Aurora console.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/Aur_PG_resource_id.png)
**To query your log files for resource storage metrics:**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
The CloudWatch overview home page appears.
1. If necessary, change the AWS Region. In the navigation bar, choose the AWS Region where your AWS resources are located. For more information, see [Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html).
1. In the navigation pane, choose **Logs** and then **Logs Insights**.
The **Logs Insights** page appears.
1. Select the log files from the drop-down list to analyze.
1. Enter the following query in the field, replacing `` with the resource ID of your DB cluster:
`filter @logStream = | parse @message "\"Aurora Storage Daemon\"*memoryUsedPc\":*,\"cpuUsedPc\":*," as a,memoryUsedPc,cpuUsedPc | display memoryUsedPc,cpuUsedPc #| stats avg(xcpu) as avgCpu by bin(5m) | limit 10000`
1. Click **Run query**.
The storage utilization graph is displayed.
The following image provides the **Logs Insights** page and the graph display.
![\[Logs Insights page and the graph display.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/AurPG-CW-LogsInsights.png)
## Evaluating DB instance usage for Aurora PostgreSQL with CloudWatch metrics
You can use CloudWatch metrics to watch your instance throughput and discover if your instance class provides sufficient resources for your applications. For information about your DB instance class limits, go to [Hardware specifications for DB instance classesfor Aurora](Concepts.DBInstanceClass.Summary.md) and locate the specifications for your DB instance class to find your network performance.
If your DB instance usage is near the instance class limit, then performance may begin to slow. The CloudWatch metrics can confirm this situation so you can plan to manually scale-up to a larger instance class.
Combine the following CloudWatch metrics values to find out if you are nearing the instance class limit:
+ **NetworkThroughput** – The amount of network throughput received and transmitted by the clients for each instance in the Aurora DB cluster. This throughput value doesn't include network traffic between instances in the DB cluster and the cluster volume.
+ **StorageNetworkThroughput** – The amount of network throughput received and sent to the Aurora storage subsystem by each instance in the Aurora DB cluster.
Add the **NetworkThroughput** to the **StorageNetworkThroughput** to find the network throughput received from and sent to the Aurora storage subsystem by each instance in your Aurora DB cluster. The instance class limit for your instance should be greater than the sum of these two combined metrics.
You can use the following metrics to review additional details of the network traffic from your client applications when sending and receiving:
+ **NetworkReceiveThroughput** – The amount of network throughput received from clients by each instance in the Aurora PostgreSQL DB cluster. This throughput doesn't include network traffic between instances in the DB cluster and the cluster volume.
+ **NetworkTransmitThroughput** – The amount of network throughput sent to clients by each instance in the Aurora DB cluster. This throughput doesn't include network traffic between instances in the DB cluster and the cluster volume.
+ **StorageNetworkReceiveThroughput** – The amount of network throughput received from the Aurora storage subsystem by each instance in the DB cluster.
+ **StorageNetworkTransmitThroughput** – The amount of network throughput sent to the Aurora storage subsystem by each instance in the DB cluster.
Add all of these metrics together to evaluate how your network usage compares to the instance class limit. The instance class limit should be greater than the sum of these combined metrics.
The network limits and CPU utilization for storage are mutual. When the network throughput increases, then the CPU utilization also increases. Monitoring the CPU and network usage provides information about how and why the resources are being exhausted.
To help minimize network usage, you can consider:
+ Using a larger instance class.
+ Using `pg_partman` partitioning strategies.
+ Dividing the write requests in batches to reduce overall transactions.
+ Directing the read-only workload to a read-only instance.
+ Deleting any unused indexes.
+ Checking for bloated objects and VACUUM. In the case of severe bloat, use the PostgreSQL extension `pg_repack`. For more information about `pg_repack`, see [Reorganize tables in PostgreSQL databases with minimal locks](https://reorg.github.io/pg_repack/).
# Using logical replication to perform a major version upgrade for Aurora PostgreSQL
Using logical replication and Aurora fast cloning, you can perform a major version upgrade that uses the current version of Aurora PostgreSQL database while gradually migrating the changing data to the new major version database. This low downtime upgrade process is referred to as a blue/green upgrade. The current version of the database is referred as the "blue" environment and the new database version is referred as the "green" environment.
Aurora fast cloning fully loads the existing data by taking a snapshot of the source database. Fast cloning uses a copy-on-write protocol built on top of the Aurora storage layer, which allows you to create a clone of database in a short time. This method is very effective when upgrading to a large database.
Logical replication in PostgreSQL tracks and transfers your data changes from initial instance to a new instance running in parallel until you move to the newer version of PostgreSQL. Logical replication uses a publish and subscribe model. For more information about Aurora PostgreSQL logical replication, see [Replication with Amazon Aurora PostgreSQL](AuroraPostgreSQL.Replication.md).
**Tip**
You can minimize the downtime required for a major version upgrade by using the managed Amazon RDS Blue/Green Deployment feature. For more information, see [Using Amazon Aurora Blue/Green Deployments for database updates](blue-green-deployments.md).
**Topics**
+ [Requirements](#AuroraPostgreSQL.MajorVersionUpgrade.Requirements)
+ [Limitations](#AuroraPostgreSQL.MajorVersionUpgrade.Limitations)
+ [Setting and checking parameter values](#AuroraPostgreSQL.MajorVersionUpgrade.Parameters)
+ [Upgrading Aurora PostgreSQL to a new major version](#AuroraPostgreSQL.MajorVersionUpgrade.StartLogicalReplication)
+ [Performing post-upgrade tasks](#AuroraPostgreSQL.MajorVersionUpgrade.PostUpgrade)
## Requirements
You must meet the following requirements to perform this low downtime upgrade process:
+ You must have rds\$1superuser permissions.
+ The Aurora PostgreSQL DB cluster you intend to upgrade must be running a supported version that can perform major version upgrades using logical replication. Make sure to apply any minor version updates and patches to your DB cluster. The `aurora_volume_logical_start_lsn` function that is used in this technique is supported in the following versions of Aurora PostgreSQL:
+ 15.2 and higher 15 versions
+ 14.3 and higher 14 versions
+ 13.6 and higher 13 versions
+ 12.10 and higher 12 versions
+ 11.15 and higher 11 versions
+ 10.20 and higher 10 versions
For more information on `aurora_volume_logical_start_lsn` function, see [aurora\$1volume\$1logical\$1start\$1lsn](aurora_volume_logical_start_lsn.md).
+ All of your tables must have a primary key or include a [PostgreSQL identity column](https://www.postgresql.org/docs/current/sql-createtable.html).
+ Configure the security group for your VPC to allow inbound and outbound access between the two Aurora PostgreSQL DB clusters, both old and new. You can grant access to a specific classless inter-domain routing (CIDR) range or to another security group in your VPC or in a peer VPC. (Peer VPC requires a VPC peering connection.)
**Note**
For detailed information about the permissions required to configure and manage a running logical replication scenario, see the [PostgreSQL core documentation](https://www.postgresql.org/docs/13/logical-replication-security.html).
## Limitations
When you are performing low downtime upgrade on your Aurora PostgreSQL DB cluster to upgrade it to a new major version, you are using the native PostgreSQL logical replication feature. It has the same capabilities and limitations as the PostgreSQL logical replication. For more information, see [PostgreSQL logical replication](https://www.postgresql.org/docs/13/logical-replication.html).
+ Data definition language (DDL) commands are not replicated.
+ Replication doesn't support schema changes in a live database. The schema is recreated in its original form during the cloning process. If you change the schema after cloning, but before completing the upgrade, it isn't reflected in the upgraded instance.
+ Large objects are not replicated, but you can store data in normal tables.
+ Replication is only supported by tables, including partitioned tables. Replication to other types of relations, such as views, materialized views, or foreign tables, is not supported.
+ Sequence data is not replicated and requires a manual update post-failover.
**Note**
This upgrade doesn't support auto-scripting. You should perform all the steps manually.
## Setting and checking parameter values
Before upgrading, configure the writer instance of your Aurora PostgreSQL DB cluster to act as a publication server. The instance should use a custom DB cluster parameter group with the following settings:
+ `rds.logical_replication` – Set this parameter to 1. The `rds.logical_replication` parameter serves the same purpose as a standalone PostgreSQL server's `wal_level` parameter and other parameters that control the write-ahead log file management.
+ `max_replication_slots` – Set this parameter to the total number of subscriptions that you plan to create. If you are using AWS DMS, set this parameter to the number of AWS DMS tasks that you plan to use for changed data capture from this DB cluster.
+ `max_wal_senders` – Set to the number of concurrent connections, plus a few extra, to make available for management tasks and new sessions. If you are using AWS DMS, the number of max\$1wal\$1senders should be equal to the number of concurrent sessions plus the number of AWS DMS tasks that may be working at any given time.
+ `max_logical_replication_workers` – Set to the number of logical replication workers and table synchronization workers that you expect. It's generally safe to set the number of replication workers to the same value used for max\$1wal\$1senders. The workers are taken from the pool of background processes (max\$1worker\$1processes) allocated for the server.
+ `max_worker_processes` – Set to the number of background processes for the server. This number should be large enough to allocate workers for replication, auto-vacuum processes, and other maintenance processes that may take place concurrently.
When you upgrade to a newer version of Aurora PostgreSQL, you need to duplicate any parameters that you modified in the earlier version of the parameter group. These parameters are applied to the upgraded version. You can query the `pg_settings` table to get a list of parameter settings so that you can re-create them on your new Aurora PostgreSQL DB cluster.
For example, to get the settings for replication parameters, run the following query:
```
SELECT name, setting FROM pg_settings WHERE name in
('rds.logical_replication', 'max_replication_slots',
'max_wal_senders', 'max_logical_replication_workers',
'max_worker_processes');
```
## Upgrading Aurora PostgreSQL to a new major version
**To prepare the publisher (blue)**
1. In the example that follows, the source writer instance (blue) is an Aurora PostgreSQL DB cluster running PostgreSQL version 11.15. This is the publication node in our replication scenario. For this demonstration, our source writer instance hosts a sample table that holds a series of values:
```
CREATE TABLE my_table (a int PRIMARY KEY);
INSERT INTO my_table VALUES (generate_series(1,100));
```
1. To create a publication on the source instance, connect to the writer node of the instance with psql (the CLI for PostgreSQL) or with the client of your choice). Enter the following command in each database:
```
CREATE PUBLICATION publication_name FOR ALL TABLES;
```
The publication\$1name specifies the name of the publication.
1. You also need to create a replication slot on the instance. The following command creates a replication slot and loads the `pgoutput` [logical decoding plug-in](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html). The plug-in changes content read from write-ahead logging (WAL) to the logical replication protocol, and filters the data according to the publication specification.
```
SELECT pg_create_logical_replication_slot('replication_slot_name', 'pgoutput');
```
**To clone the publisher**
1. Use the Amazon RDS Console to create a clone of the source instance. Highlight the instance name in the Amazon RDS Console, and then choose **Create clone** in the **Actions** menu.
![\[In-place upgrade of an Aurora MySQL DB cluster from version 2 to version 3\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-logicalreplication-mvu-create-clone.png)
1. Provide a unique name for the instance. Most of the settings are defaults from the source instance. When you’ve made changes required for the new instance, choose **Create clone**.
![\[In-place upgrade of an Aurora MySQL DB cluster from version 2 to version 3\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-logicalreplication-mvu-create-clone-note.png)
1. While the target instance is initiating, the **Status** column of the writer node displays Creating in the **Status** column. When the instance is ready, the status changes to Available.
**To prepare the clone for an upgrade**
1. The clone is the ‘green’ instance in the deployment model. It is the host of the replication subscription node. When the node becomes available, connect with psql and query the new writer node to obtain the log sequence number (LSN). The LSN identifies the beginning of a record in the WAL stream.
```
SELECT aurora_volume_logical_start_lsn();
```
1. In the response from the query, you find the LSN number. You need this number later in the process, so make a note of it.
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
1. Before upgrading the clone, drop the clone's replication slot.
```
SELECT pg_drop_replication_slot('replication_slot_name');
```
**To upgrade the cluster to a new major version**
+ After cloning the provider node, use the Amazon RDS Console to initiate a major version upgrade on the subscription node. Highlight the instance name in the RDS console, and select the **Modify** button. Select the updated version and your updated parameter groups, and apply the settings immediately to upgrade the target instance.
![\[In-place upgrade of an Aurora MySQL DB cluster from version 2 to version 3\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-logicalreplication-mvu-modify-DB-cluster.png)
+ You can also use the CLI to perform an upgrade:
```
aws rds modify-db-cluster —db-cluster-identifier $TARGET_Aurora_ID —engine-version 13.6 —allow-major-version-upgrade —apply-immediately
```
**To prepare the subscriber (green)**
1. When the clone becomes available after the upgrade, connect with psql and define the subscription. To do so, you need to specify the following options in the `CREATE SUBSCRIPTION` command:
+ `subscription_name` – The name of the subscription.
+ `admin_user_name` – The name of an administrative user with rds\$1superuser permissions.
+ `admin_user_password` – The password associated with the administrative user.
+ `source_instance_URL` – The URL of the publication server instance.
+ `database` – The database that the subscription server will connect with.
+ `publication_name` – The name of the publication server.
+ `replication_slot_name` – The name of the replication slot.
```
CREATE SUBSCRIPTION subscription_name
CONNECTION 'postgres://admin_user_name:admin_user_password@source_instance_URL/database' PUBLICATION publication_name
WITH (copy_data = false, create_slot = false, enabled = false, connect = true, slot_name = 'replication_slot_name');
```
1. After creating the subscription, query the [pg\$1replication\$1origin](https://www.postgresql.org/docs/14/catalog-pg-replication-origin.html) view to retrieve the roname value, which is the identifier of the replication origin. Each instance has one `roname`:
```
SELECT * FROM pg_replication_origin;
```
For example:
```
postgres=>
SELECT * FROM pg_replication_origin;
roident | roname
---------+----------
1 | pg_24586
```
1. Provide the LSN that you saved from the earlier query of the publication node and the `roname` returned from the subscription node [INSTANCE] in the command. This command uses the `[pg\$1replication\$1origin\$1advance](https://www.postgresql.org/docs/14/functions-admin.html)` function to specify the starting point in the log sequence for replication.
```
SELECT pg_replication_origin_advance('roname', 'log_sequence_number');
```
`roname` is the identifier returned by the pg\$1replication\$1origin view.
`log_sequence_number` is the value returned by the earlier query of the `aurora_volume_logical_start_lsn` function.
1. Then, use the `ALTER SUBSCRIPTION... ENABLE` clause to turn on logical replication.
```
ALTER SUBSCRIPTION subscription_name ENABLE;
```
1. At this point, you can confirm that replication is working. Add a value to the publication instance, then confirm that the value is replicated to the subscription node.
Then, use the following command to monitor replication lag on the publication node:
```
SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
```
For example:
```
postgres=> SELECT now() AS CURRENT_TIME, slot_name, active, active_pid, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),
confirmed_flush_lsn)) AS diff_size, pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS diff_bytes FROM pg_replication_slots WHERE slot_type = 'logical';
current_time | slot_name | active | active_pid | diff_size | diff_bytes
-------------------------------+-----------------------+--------+------------+-----------+------------
2022-04-13 15:11:00.243401+00 | replication_slot_name | t | 21854 | 136 bytes | 136
(1 row)
```
You can monitor the replication lag using `diff_size` and `diff_bytes` values. When these values reach 0, the replica has caught up to the source DB instance.
## Performing post-upgrade tasks
When the upgrade is complete, the instance status displays as **Available** in the **Status** column of the console dashboard. On the new instance, we recommend you do the following:
+ Redirect your applications to point to the writer node.
+ Add reader nodes to manage the caseload and provide high-availability in the event of an issue with the writer node.
+ Aurora PostgreSQL DB clusters occasionally require operating system updates. These updates might include a newer version of glibc library. During such updates, we recommend you to follow the guidelines as described in [Collations supported in Aurora PostgreSQL ](PostgreSQL-Collations.md).
+ Update user permissions on the new instance to ensure access.
After testing your application and data on the new instance, we recommend that you make a final backup of your initial instance before removing it. For more information about using logical replication on an Aurora host, see [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md).
# Managing custom casts in Aurora PostgreSQL
**Type casting** in PostgreSQL is the process of converting a value from one data type to another. PostgreSQL provides built-in casts for many common conversions, but you can also create custom casts to define how specific type conversions should behave.
A cast specifies how to perform a conversion from one data type to another. For example, converting text `'123'` to integer `123`, or numeric `45.67` to text `'45.67'`.
For comprehensive information about PostgreSQL casting concepts and syntax, refer to the [PostgreSQL CREATE CAST Documentation](https://www.postgresql.org/docs/current/sql-createcast.html).
Starting with Aurora PostgreSQL versions 13.23, 14.20, 15.15, 16.11, 17.7, and 18.1, you can use the rds\$1casts extension to install additional casts for built-in types, while still being able to create your own casts for custom types.
**Topics**
+ [Installing and using the rds\$1casts extension](#PostgreSQL.CustomCasts.Installing)
+ [Supported casts](#PostgreSQL.CustomCasts.Supported)
+ [Creating or dropping casts](#PostgreSQL.CustomCasts.Creating)
+ [Creating custom casts with proper context strategy](#PostgreSQL.CustomCasts.BestPractices)
## Installing and using the rds\$1casts extension
To create the `rds_casts` extension, connect to the writer instance of your Aurora PostgreSQL DB cluster as an `rds_superuser` and run the following command:
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Supported casts
Create the extension in each database where you want to use custom casts. After creating the extension, use the following command to view all available casts:
```
SELECT * FROM rds_casts.list_supported_casts();
```
This function lists the available cast combinations (source type, target type, coercion context, and cast function). For example, if you want to create `text` to `numeric` as an `implicit` cast. You can use the following query to find if the cast is available to create:
```
SELECT * FROM rds_casts.list_supported_casts()
WHERE source_type = 'text' AND target_type = 'numeric';
id | source_type | target_type | qualified_function | coercion_context
----+-------------+-------------+--------------------------------------+------------------
10 | text | numeric | rds_casts.rds_text_to_numeric_custom | implicit
11 | text | numeric | rds_casts.rds_text_to_numeric_custom | assignment
13 | text | numeric | rds_casts.rds_text_to_numeric_custom | explicit
20 | text | numeric | rds_casts.rds_text_to_numeric_inout | implicit
21 | text | numeric | rds_casts.rds_text_to_numeric_inout | assignment
23 | text | numeric | rds_casts.rds_text_to_numeric_inout | explicit
```
The rds\$1casts extension provides two types of conversion functions for each cast:
+ *\$1inout functions* - Use PostgreSQL's standard I/O conversion mechanism, behaving identically to casts created with the INOUT method
+ *\$1custom functions* - Provide enhanced conversion logic that handles edge cases, such as converting empty strings to NULL values to avoid conversion errors
The `inout` functions replicate PostgreSQL's native casting behavior, while `custom` functions extend this functionality by handling scenarios that standard INOUT casts cannot accommodate, such as converting empty strings to integers.
## Creating or dropping casts
You can create and drop supported casts using two methods:
### Cast creation
**Method 1: Using native CREATE CAST command**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Method 2: Using the rds\$1casts.create\$1cast function**
```
SELECT rds_casts.create_cast(10);
```
The `create_cast` function takes the ID from the `list_supported_casts()` output. This method is simpler and ensures you're using the correct function and context combination. This id is guaranteed to remain the same across different postgres versions.
To verify the cast was created successfully, query the pg\$1cast system catalog:
```
SELECT oid, castsource::regtype, casttarget::regtype, castfunc::regproc, castcontext, castmethod
FROM pg_cast
WHERE castsource = 'text'::regtype AND casttarget = 'numeric'::regtype;
oid | castsource | casttarget | castfunc | castcontext | castmethod
--------+------------+------------+--------------------------------------+-------------+------------
356372 | text | numeric | rds_casts.rds_text_to_numeric_custom | i | f
```
The `castcontext` column shows: `e` for EXPLICIT, `a` for ASSIGNMENT, or `i` for IMPLICIT.
### Dropping casts
**Method 1: Using DROP CAST command**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Method 2: Using the rds\$1casts.drop\$1cast function**
```
SELECT rds_casts.drop_cast(10);
```
The `drop_cast` function takes the same ID used when creating the cast. This method ensures you're dropping the exact cast that was created with the corresponding ID.
## Creating custom casts with proper context strategy
When creating multiple casts for integer types, operator ambiguity errors can occur if all casts are created as IMPLICIT. The following example demonstrates this issue by creating two implicit casts from text to different integer widths:
```
-- Creating multiple IMPLICIT casts causes ambiguity
postgres=> CREATE CAST (text AS int4) WITH FUNCTION rds_casts.rds_text_to_int4_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE CAST (text AS int8) WITH FUNCTION rds_casts.rds_text_to_int8_custom(text) AS IMPLICIT;
CREATE CAST
postgres=> CREATE TABLE test_cast(col int);
CREATE TABLE
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
ERROR: operator is not unique: integer = text
LINE 1: SELECT * FROM test_cast WHERE col='123'::text;
^
HINT: Could not choose a best candidate operator. You might need to add explicit type casts.
```
The error occurs because PostgreSQL cannot determine which implicit cast to use when comparing an integer column with a text value. Both the int4 and int8 implicit casts are valid candidates, creating ambiguity.
To avoid this operator ambiguity, use ASSIGNMENT context for smaller integer widths and IMPLICIT context for larger integer widths:
```
-- Use ASSIGNMENT for smaller integer widths
CREATE CAST (text AS int2)
WITH FUNCTION rds_casts.rds_text_to_int2_custom(text)
AS ASSIGNMENT;
CREATE CAST (text AS int4)
WITH FUNCTION rds_casts.rds_text_to_int4_custom(text)
AS ASSIGNMENT;
-- Use IMPLICIT for larger integer widths
CREATE CAST (text AS int8)
WITH FUNCTION rds_casts.rds_text_to_int8_custom(text)
AS IMPLICIT;
postgres=> INSERT INTO test_cast VALUES ('123'::text);
INSERT 0 1
postgres=> SELECT * FROM test_cast WHERE col='123'::text;
col
-----
123
(1 row)
```
With this strategy, only the int8 cast is implicit, so PostgreSQL can unambiguously determine which cast to use.
# Best Practices for Parallel Queries in Aurora PostgreSQL
Parallel query execution is a feature in PostgreSQL that allows a single SQL query to be broken into smaller tasks that are processed simultaneously by multiple background worker processes. Instead of executing a query entirely in a single backend process, PostgreSQL can distribute parts of the query, such as scans, joins, aggregations, or sorting, across multiple CPU cores. The *leader process* coordinates this execution and gathers the results from the *parallel workers*.
However, for most production workloads, especially high-concurrency OLTP systems, we recommend disabling automatic parallel query execution. While parallelism can accelerate queries on large datasets in analytics or reporting workloads, it introduces significant risks that often outweigh the benefits in busy production environments.
Parallel execution also introduces significant overhead. Each parallel worker is a full PostgreSQL backend process, which requires process forking (copying memory structures and initializing process state) and authentication (consuming connection slots from your `max_connections` limit). Each worker also consumes its own memory, including `work_mem` for sorting and hashing operations, with multiple workers per query, memory usage multiplies quickly (e.g., 4 workers × 64MB `work_mem` = 256MB per query). As a result, parallel queries can consume considerably more system resources than single-process queries. If not tuned properly, they may lead to CPU saturation (multiple workers overwhelming available processing capacity), increased context switching (the operating system frequently switching between numerous worker processes, adding overhead and reducing throughput), or connection exhaustion (since each parallel worker consumes a connection slot, a single query with 4 workers uses 5 connections total, 1 leader \$1 4 workers, which can quickly exhaust your connection pool under high concurrency, preventing new client connections and causing application failures). These issues are particularly severe under high-concurrency workloads where multiple queries may attempt parallel execution simultaneously.
PostgreSQL decides whether to use parallelism based on cost estimates. In some cases, the planner may automatically switch to a parallel plan if it appears cheaper even when it's not ideal in practice. This can happen if index statistics are outdated or if bloat makes sequential scans appear more attractive than index lookups. Because of this behavior, automatic parallel plans can sometimes introduce regressions in query performance or system stability.
To get the most benefit from parallel queries in Aurora PostgreSQL, it's important to test and tune them based on your workload, monitor system impact, and disable automatic parallel plan selection in favor of query-level control.
## Configuration Parameters
PostgreSQL uses several parameters to control the behavior and availability of parallel queries. Understanding and tuning these is critical to achieving predictable performance:
| Parameter | Description | Default |
| --- | --- | --- |
| max\$1parallel\$1workers | Maximum number of background worker processes that can run in total | GREATEST(\$1DBInstanceVCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Maximum number of workers per query plan node (e.g., per Gather) | 2 |
| parallel\$1setup\$1cost | Planner cost added for initiating parallel query infrastructure | 1000 |
| parallel\$1tuple\$1cost | Cost per tuple processed in parallel mode (impacts planner decision) | 0.1 |
| force\$1parallel\$1mode | Forces planner to test parallel plans (off, on, regress) | off |
### Key Considerations
+ `max_parallel_workers` controls the total pool of parallel workers. If set too low, some queries may fall back to serial execution.
+ `max_parallel_workers_per_gather` affects how many workers a single query can use. A higher value increases concurrency, but also resource usage.
+ `parallel_setup_cost` and `parallel_tuple_cost` affect the planner's cost model. Lowering these can make parallel plans more likely to be chosen.
+ `force_parallel_mode` is useful for testing but should not be used in production unless necessary.
**Note**
The default value of the `max_parallel_workers` parameter is dynamically calculated based on instance size using the formula `GREATEST($DBInstanceVCPU/2, 8)`. This means that when you scale your Aurora instance to a larger compute size with more vCPUs, the maximum number of available parallel workers will automatically increase. As a result, queries that previously executed serially or with limited parallelism may suddenly utilize more parallel workers after a scale-up operation, potentially leading to unexpected increases in connection usage, CPU utilization, and memory consumption. It's important to monitor parallel query behavior after any compute scaling event and adjust `max_parallel_workers_per_gather` if necessary to maintain predictable resource usage.
## Identify Parallel Queries Usage
Queries may flip to parallel plans based on data distribution or statistics. For example:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
This query might use an index for recent data, but switch to a parallel sequential scan for historical data.
You can log query execution plans by loading the `auto_explain` module. To learn more, see [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) in the AWS knowledge center.
You can monitor query execution plans in your Aurora PostgreSQL DB instance to detect the execution plans contributing to current database load and to track performance statistics of execution plans over time using the `aurora_compute_plan_id` parameter. To learn more, see [Monitoring query execution plans and peak memory for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
You can monitor [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) for Parallel Query related wait events. To learn more about Parallel Query related wait events, go through [IPC:parallel wait events](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html)
From PostgreSQL version 18, you can monitor parallel worker activity using new columns in [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW) and [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html):
+ `parallel_workers_to_launch`: Number of parallel workers planned to be launched
+ `parallel_workers_launched`: Number of parallel workers actually launched
These metrics help identify discrepancies between planned and actual parallelism, which can indicate resource constraints or configuration issues. Use the following queries to monitor parallel execution:
For Database-level parallel worker metrics:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
For Query-level parallel worker metrics
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## How to Control Parallelism
There are several ways to control query parallelism, each designed for different scenarios and requirements.
To disable automatic parallelism globally, [modify your parameter group](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.Modifying.html) to set:
```
max_parallel_workers_per_gather = 0;
```
For persistent, user-specific settings, the ALTER ROLE command provides a way to set parameters that will apply to all future sessions for a particular user.
For example:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;` ensures that every time this user connects to the database, their sessions will use this parallel worker setting when required.
Session-level control can be achieved using the SET command, which modifies parameters for the duration of the current database session. This is particularly useful when you need to temporarily adjust settings without affecting other users or future sessions. Once set, these parameters remain in effect until explicitly reset or until the session ends. The commands are straightforward:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
For even more granular control, SET LOCAL allows you to modify parameters for a single transaction. This is ideal when you need to adjust settings for a specific set of queries within a transaction, after which the settings automatically revert to their previous values. This approach helps prevent unintended effects on other operations within the same session.
### Utilize Query Plan Management (QPM)
In Aurora PostgreSQL, the Query Plan Management (QPM) feature is designed to ensure plan adaptability and stability, regardless of database environment changes that might cause query plan regression. For more information, see [Overview of Aurora PostgreSQL query plan management](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.overview.html). QPM provides some control over the optimizer. Review approved plans in QPM to ensure they align with current parallelism settings. Update or remove outdated plans that may be forcing suboptimal parallel execution.
You can also fix the plans using pg\$1hint\$1plan. For more information, see [Fixing plans using pg\$1hint\$1plan](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Maintenance.html#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). You can use the hint named `Parallel` to enforce parallel execution. For more information, see the [Hints for parallel plans](https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_table.md#hints-for-parallel-plans).
## Diagnosing Parallel Query Behavior
Use `EXPLAIN (ANALYZE, VERBOSE)` to confirm whether a query used parallel execution:
+ Look for nodes such as `Gather`, `Gather Merge`, or `Parallel Seq Scan`.
+ Compare plans with and without parallelism.
To disable parallelism temporarily for comparison:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Troubleshooting storage issues in Aurora PostgreSQL
If the amount of working memory needed for sort or index-creation operations exceeds the amount allocated by the `work_mem` parameter, Aurora PostgreSQL writes the excess data to temporary disk files. When it writes the data, Aurora PostgreSQL uses the same storage space that it uses for storing error and message logs, that is, *local storage*. Each instance in your Aurora PostgreSQL DB cluster has an amount of local storage available. The amount of storage is based on its DB instance class. To increase the amount of local storage, you need to modify the instance to use a larger DB instance class. For DB instance class specifications, see [Hardware specifications for DB instance classesfor Aurora](Concepts.DBInstanceClass.Summary.md).
You can monitor your Aurora PostgreSQL DB cluster's local storage space by watching the Amazon CloudWatch metric for `FreeLocalStorage`. This metric reports the amount of storage available to each DB instance in the Aurora DB cluster for temporary tables and logs. For more information, see [Monitoring Amazon Aurora metrics with Amazon CloudWatch](monitoring-cloudwatch.md).
Sorting, indexing, and grouping operations start in working memory but often must be offloaded to local storage. If your Aurora PostgreSQL DB cluster runs out of local storage because of these types of operations, you can resolve the issue by taking one of the following actions.
+ Increase the amount of working memory. This reduces the need to use local storage. By default, PostgreSQL allocates 4 MB for each sort, group, and index operation. To check the current working memory value for your Aurora PostgreSQL DB cluster's writer instance, connect to the instance using `psql` and run the following command.
```
postgres=> SHOW work_mem;
work_mem
----------
4MB
(1 row)
```
You can increase the working memory at the session level before sort, group, and other operations, as follows.
```
SET work_mem TO '1 GB';
```
For more information about working memory, see [Resource Consumption](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY) in the PostgreSQL documentation.
+ Change the log retention period so that logs are stored for shorter timeframes. To learn how, see [Aurora PostgreSQL database log files](USER_LogAccess.Concepts.PostgreSQL.md).
For Aurora PostgreSQL DB clusters larger than 40 TB, don't use db.t2, db.t3, or db.t4g instance classes. We recommend using the T DB instance classes only for development and test servers, or other non-production servers. For more information, see [DB instance class types](Concepts.DBInstanceClass.Types.md).
# Replication with Amazon Aurora PostgreSQL
Following, you can find information about replication with Amazon Aurora PostgreSQL, including how to monitor and use logical replication.
**Topics**
+ [Using Aurora Replicas](#AuroraPostgreSQL.Replication.Replicas)
+ [Improving the read availability of Aurora Replicas](#AuroraPostgreSQL.Replication.Replicas.SRO)
+ [Monitoring Aurora PostgreSQL replication](#AuroraPostgreSQL.Replication.Monitoring)
+ [Overview of PostgreSQL logical replication with Aurora](AuroraPostgreSQL.Replication.Logical.md)
+ [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md)
+ [Turning off logical replication](AuroraPostgreSQL.Replication.Logical.Stop.md)
+ [Monitoring the write-through cache and logical slots for Aurora PostgreSQL logical replication](AuroraPostgreSQL.Replication.Logical-monitoring.md)
+ [Example: Using logical replication with Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md)
+ [Example: Logical replication using Aurora PostgreSQL and AWS Database Migration Service](AuroraPostgreSQL.Replication.Logical.DMS-Example.md)
+ [Configuring IAM authentication for logical replication connections](AuroraPostgreSQL.Replication.Logical.IAM-auth.md)
## Using Aurora Replicas
An *Aurora Replica* is an independent endpoint in an Aurora DB cluster, best used for scaling read operations and increasing availability. An Aurora DB cluster can include up to 15 Aurora Replicas located throughout the Availability Zones of the Aurora DB cluster's AWS Region.
The DB cluster volume is made up of multiple copies of the data for the DB cluster. However, the data in the cluster volume is represented as a single, logical volume to the primary writer DB instance and to Aurora Replicas in the DB cluster. For more information about Aurora Replicas, see [Aurora Replicas](Aurora.Replication.md#Aurora.Replication.Replicas).
Aurora Replicas work well for read scaling because they're fully dedicated to read operations on your cluster volume. The writer DB instance manages write operations. The cluster volume is shared among all instances in your Aurora PostgreSQL DB cluster. Thus, no extra work is needed to replicate a copy of the data for each Aurora Replica.
With Aurora PostgreSQL, when an Aurora Replica is deleted, its instance endpoint is removed immediately, and the Aurora Replica is removed from the reader endpoint. If there are statements running on the Aurora Replica that is being deleted, there is a three minute grace period. Existing statements can finish gracefully during the grace period. When the grace period ends, the Aurora Replica is shut down and deleted.
Aurora PostgreSQL DB clusters support Aurora Replicas in different AWS Regions, using Aurora global database. For more information, see [Using Amazon Aurora Global Database](aurora-global-database.md).
**Note**
With the read availability feature, if you want to reboot the Aurora Replicas in the DB cluster, you have to perform it manually. For the DB clusters created prior to this feature rebooting the writer DB instance automatically reboots the Aurora Replicas. The automatic reboot re-establishes an entry point that guarantees read/write consistency across the DB cluster.
## Improving the read availability of Aurora Replicas
Aurora PostgreSQL improves the read availability in the DB cluster by continuously serving the read requests when the writer DB instance restarts or when the Aurora Replica is unable to keep up with the write traffic.
The read availability feature is available by default on the following versions of Aurora PostgreSQL:
+ 16.1 and all higher versions
+ 15.2 and higher 15 versions
+ 14.7 and higher 14 versions
+ 13.10 and higher 13 versions
+ 12.14 and higher 12 versions
The read availability feature is supported by Aurora global database in the following versions:
+ 16.1 and all higher versions
+ 15.4 and higher 15 versions
+ 14.9 and higher 14 versions
+ 13.12 and higher 13 versions
+ 12.16 and higher 12 versions
To use the read availability feature for a DB cluster created on one of these versions prior to this launch, restart the writer instance of the DB cluster.
When you modify static parameters of your Aurora PostgreSQL DB cluster, you must restart the writer instance so that the parameter changes take effect. For example, you must restart the writer instance when you set the value of `shared_buffers`. With the read availability feature of Aurora Replicas, the DB cluster maintains improved availability, reducing the impact on it when the writer instance restarts. The reader instances don't restart and continue to respond to the read requests. To apply static parameter changes, reboot each individual reader instance.
An Aurora PostgreSQL DB cluster's Aurora Replica can recover from replication errors such as writer restarts, failover, slow replication, and network issues by quickly recovering to in-memory database state after it reconnects with the writer. This approach allows Aurora Replica instances to reach consistency with the latest storage updates while the client database is still available.
The in-progress transactions that conflict with replication recovery might receive an error but the client can retry these transactions, after the readers catch up with the writer.
### Monitoring Aurora Replicas
You can monitor the Aurora Replicas when recovering from a writer disconnect. Use the metrics below to check for the latest information about the reader instance and to track in-process read-only transactions.
+ The `aurora_replica_status` function is updated to return the most up-to-date information for the reader instance when it is still connected. The last update time stamp in `aurora_replica_status` is always empty for the row corresponding to the DB instance that the query is executed on. This indicates that the reader instance has the latest data.
+ When the Aurora replica disconnects from the writer instance and reconnects back, the following database event is emitted:
`Read replica has been disconnected from the writer instance and reconnected.`
+ When a read-only query is canceled due to a recovery conflict, you might see one or more of the following error messages in the database error log:
`Canceling statement due to conflict with recovery`.
`User query may not have access to page data to replica disconnect.`
`User query might have tried to access a file that no longer exists.`
`When the replica reconnects, you will be able to repeat your command.`
### Limitations
The following limitations apply to Aurora Replicas with the read availability feature:
+ Aurora Replicas of secondary DB cluster can restart if the data can't be streamed from the writer instance during replication recovery.
+ Aurora Replicas don't support online replication recovery if one is already in progress and will restart.
+ Aurora Replicas will restart when your DB instance is nearing the transaction ID wraparound. For more information on transaction ID wraparound, see [Preventing Transaction ID Wraparound Failures](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND ).
+ Aurora Replicas can restart when the replication process is blocked under certain circumstances.
## Monitoring Aurora PostgreSQL replication
Read scaling and high availability depend on minimal lag time. You can monitor how far an Aurora Replica is lagging behind the writer DB instance of your Aurora PostgreSQL DB cluster by monitoring the Amazon CloudWatch `ReplicaLag` metric. Because Aurora Replicas read from the same cluster volume as the writer DB instance, the `ReplicaLag` metric has a different meaning for an Aurora PostgreSQL DB cluster. The `ReplicaLag` metric for an Aurora Replica indicates the lag for the page cache of the Aurora Replica compared to that of the writer DB instance.
For more information on monitoring RDS instances and CloudWatch metrics, see [Monitoring metrics in an Amazon Aurora cluster](MonitoringAurora.md).
# Overview of PostgreSQL logical replication with Aurora
By using PostgreSQL's logical replication feature with your Aurora PostgreSQL DB cluster, you can replicate and synchronize individual tables rather than the entire database instance. Logical replication uses a publish and subscribe model to replicate changes from a source to one or more recipients. It works by using change records from the PostgreSQL write-ahead log (WAL). The source, or *publisher*, sends WAL data for the specified tables to one or more recipients (*subscriber*), thus replicating the changes and keeping a subscriber's table synchronized with the publisher's table. The set of changes from the publisher are identified using a *publication*. Subscribers get the changes by creating a *subscription* that defines the connection to the publisher's database and its publications. A *replication slot* is the mechanism used in this scheme to track progress of a subscription.
For Aurora PostgreSQL DB clusters, the WAL records are saved on Aurora storage. The Aurora PostgreSQL DB cluster that's acting as the publisher in a logical replication scenario reads the WAL data from Aurora storage, decodes it, and sends it to the subscriber so that the changes can be applied to the table on that instance. The publisher uses a *logical decoder* to decode the data for use by subscribers. By default, Aurora PostgreSQL DB clusters use the native PostgreSQL `pgoutput` plugin when sending data. Other logical decoders are available. For example, Aurora PostgreSQL also supports the `[wal2json](https://github.com/eulerto/wal2json)` plugin that converts WAL data to JSON.
As of Aurora PostgreSQL version 14.5, 13.8, 12.12, and 11.17, Aurora PostgreSQL augments the PostgreSQL logical replication process with a *write-through cache* to improve performance. The WAL transaction logs are cached locally, in a buffer, to reduce the amount of disk I/O, that is, reading from Aurora storage during logical decoding. The write-through cache is used by default whenever you use logical replication for your Aurora PostgreSQL DB cluster. Aurora provides several functions that you can use to manage the cache. For more information, see [Monitoring the Aurora PostgreSQL logical replication write-through cache](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache).
Logical replication is supported by all currently available Aurora PostgreSQL versions. For more information, [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) in the *Release Notes for Aurora PostgreSQL*.
Logical replication is supported by Babelfish for Aurora PostgreSQL from the following versions:
+ 15.7 and higher versions
+ 16.3 and higher versions
**Note**
In addition to the native PostgreSQL logical replication feature introduced in PostgreSQL 10, Aurora PostgreSQL also supports the `pglogical` extension. For more information, see [Using pglogical to synchronize data across instances](Appendix.PostgreSQL.CommonDBATasks.pglogical.md).
For more information about PostgreSQL logical replication, see [Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) and [Logical decoding concepts](https://www.postgresql.org/docs/current/logicaldecoding-explanation.html) in the PostgreSQL documentation.
**Note**
PostgreSQL 16 added support for logical decoding from read replicas. This feature isn't supported on Aurora PostgreSQL.
# Setting up logical replication for your Aurora PostgreSQL DB cluster
Setting up logical replication requires `rds_superuser` privileges. Your Aurora PostgreSQL DB cluster must be configured to use a custom DB cluster parameter group so that you can set the necessary parameters as detailed in the procedure following. For more information, see [DB cluster parameter groups for Amazon Aurora DB clusters](USER_WorkingWithDBClusterParamGroups.md).
**To set up PostgreSQL logical replication for an Aurora PostgreSQL DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose your Aurora PostgreSQL DB cluster.
1. Open the **Configuration** tab. Among the Instance details, find the **Parameter group** link with **DB cluster parameter group** for **Type**.
1. Choose the link to open the custom parameters associated with your Aurora PostgreSQL DB cluster.
1. In the **Parameters** search field, type `rds` to find the `rds.logical_replication` parameter. The default value for this parameter is `0`, meaning that it's turned off by default.
1. Choose **Edit parameters** to access the property values, and then choose `1` from the selector to turn on the feature. Depending on your expected usage, you might also need to change the settings for the following parameters. However, in many cases, the default values are sufficient.
+ `max_replication_slots` – Set this parameter to a value that's at least equal to your planned total number of logical replication publications and subscriptions. If you are using AWS DMS, this parameter should equal at least your planned change data capture tasks from the cluster, plus logical replication publications and subscriptions.
+ `max_wal_senders` and `max_logical_replication_workers` – Set these parameters to a value that's at least equal to the number of logical replication slots that you intend to be active, or the number of active AWS DMS tasks for change data capture. Leaving a logical replication slot inactive prevents the vacuum from removing obsolete tuples from tables, so we recommend that you monitor replication slots and remove inactive slots as needed.
+ `max_worker_processes` – Set this parameter to a value that's at least equal to the total of the `max_logical_replication_workers`, `autovacuum_max_workers`, and `max_parallel_workers` values. On small DB instance classes, background worker processes can affect application workloads, so monitor the performance of your database if you set `max_worker_processes` higher than the default value. (The default value is the result of `GREATEST(${DBInstanceVCPU*2},8}`, which means that, by default, this is either 8 or twice the CPU equivalent of the DB instance class, whichever is greater).
**Note**
You can modify parameter values in a customer-created DB parameter group. you can't change the parameter values in a default DB parameter group.
1. Choose **Save changes**.
1. Reboot the writer instance of your Aurora PostgreSQL DB cluster so that your changes takes effect. In the Amazon RDS console, choose the primary DB instance of the cluster and choose **Reboot** from the **Actions** menu.
1. When the instance is available, you can verify that logical replication is turned on, as follows.
1. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Verify that logical replication has been enabled by using the following command.
```
labdb=> SHOW rds.logical_replication;
rds.logical_replication
-------------------------
on
(1 row)
```
1. Verify that the `wal_level` is set to `logical`.
```
labdb=> SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
For an example of using logical replication to keep a database table synchronized with changes from a source Aurora PostgreSQL DB cluster, see [Example: Using logical replication with Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
# Turning off logical replication
After completing your replication tasks, you should stop the replication process, drop replication slots, and turn off logical replication. Before dropping slots, make sure that they're no longer needed. Active replication slots can't be dropped.
**To turn off logical replication**
1. Drop all replication slots.
To drop all of the replication slots, connect to the publisher and run the following SQL command.
```
SELECT pg_drop_replication_slot(slot_name)
FROM pg_replication_slots
WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);
```
The replication slots can't be active when you run this command.
1. Modify the custom DB cluster parameter group associated with the publisher as detailed in [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md), but set the `rds.logical_replication` parameter to 0.
For more information about custom parameter groups, see [Modifying parameters in a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Restart the publisher Aurora PostgreSQL DB cluster for the change to the `rds.logical_replication` parameter to take effect.
# Monitoring the write-through cache and logical slots for Aurora PostgreSQL logical replication
Monitor the logical replication write-through cache and manage logical slots to improve performance for your Aurora PostgreSQL DB cluster. Following, find more information about the write-through cache and logical slots.
**Topics**
+ [Monitoring the Aurora PostgreSQL logical replication write-through cache](#AuroraPostgreSQL.Replication.Logical-write-through-cache)
+ [Managing logical slots for Aurora PostgreSQL](#AuroraPostgreSQL.Replication.Logical.Configure.managing-logical-slots)
## Monitoring the Aurora PostgreSQL logical replication write-through cache
By default, Aurora PostgreSQL versions 14.5, 13.8, 12.12, and 11.17 and higher use a write-through cache to improve the performance for logical replication. Without the write-through cache, Aurora PostgreSQL uses the Aurora storage layer in its implementation of the native PostgreSQL logical replication process. It does so by writing WAL data to storage and then reading the data back from storage to decode it and send (replicate) to its targets (subscribers). This can result in bottlenecks during logical replication for Aurora PostgreSQL DB clusters.
The write-through cache minimizes reliance on the Aurora storage layer. Instead of consistently writing to and reading from this layer, Aurora PostgreSQL uses a buffer to cache the logical WAL stream for use during the replication process, reducing the need to access disk. This buffer is the native PostgreSQL cache used in logical replication and is identified in Aurora PostgreSQL DB cluster parameters as `rds.logical_wal_cache`.
When you use logical replication with your Aurora PostgreSQL DB cluster (for the versions that support the write-through cache), you can monitor the cache hit ratio to see how well it's working for your use case. To do so, connect to your Aurora PostgreSQL DB cluster's write instance using `psql` and then use the Aurora function, `aurora_stat_logical_wal_cache`, as shown in the following example.
```
SELECT * FROM aurora_stat_logical_wal_cache();
```
The function returns output such as the following.
```
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
-----------+------------+-----------+------------+-----------+----------+--------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39...
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34...
(2 rows)
```
The `last_reset_timestamp` values have been shortened for readability. For more information about this function, see [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
Aurora PostgreSQL provides the following two functions for monitoring the write-through cache.
+ The `aurora_stat_logical_wal_cache` function – For reference documentation, see [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md).
+ The `aurora_stat_reset_wal_cache` function – For reference documentation, see [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md).
If you find that the automatically adjusted WAL cache size isn't sufficient for your workloads, you can change the the value of the `rds.logical_wal_cache` manually. Consider the following:
+ When the `rds.logical_replication` parameter is disabled, `rds.logical_wal_cache` is set to zero (0).
+ When the `rds.logical_replication` parameter is enabled, `rds.logical_wal_cache` has a default value of 16 MB.
+ The `rds.logical_wal_cache` parameter is static and requires a database instance reboot for changes to take effect. This parameter is defined in terms of 8 Kb blocks. Note that any positive value less than 32 Kb is treated as 32 Kb. For more information about `wal_buffers` see [Write Ahead Log](https://www.postgresql.org/docs/current/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) in the PostgreSQL documentation.
## Managing logical slots for Aurora PostgreSQL
Streaming activity is captured in the `pg_replication_origin_status` view. To see the contents of this view, you can use the `pg_show_replication_origin_status()` function, as shown following:
```
SELECT * FROM pg_show_replication_origin_status();
```
You can get a list of your logical slots by using the following SQL query.
```
SELECT * FROM pg_replication_slots;
```
To drop a logical slot, use the `pg_drop_replication_slot` with the name of the slot, as shown in the following command.
```
SELECT pg_drop_replication_slot('test_slot');
```
# Example: Using logical replication with Aurora PostgreSQL DB clusters
The following procedure shows you how to start logical replication between two Aurora PostgreSQL DB clusters. Both the publisher and the subscriber must be configured for logical replication as detailed in [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md).
The Aurora PostgreSQL DB cluster that's the designated publisher must also allow access to the replication slot. To do so, modify the security group associated with the Aurora PostgreSQL DB cluster 's virtual public cloud (VPC) based on the Amazon VPC service. Allow inbound access by adding the security group associated with the subscriber's VPC to the publisher's security group. For more information, see [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) in the *Amazon VPC User Guide*.
With these preliminary steps complete, you can use PostgreSQL commands `CREATE PUBLICATION` on the publisher and the `CREATE SUBSCRIPTION` on the subscriber, as detailed in the following procedure.
**To start the logical replication process between two Aurora PostgreSQL DB clusters**
These steps assume that your Aurora PostgreSQL DB clusters have a writer instance with a database in which to create the example tables.
1. **On the publisher Aurora PostgreSQL DB cluster**
1. Create a table using the following SQL statement.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Insert data into the publisher database by using the following SQL statement.
```
INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
```
1. Verify that data exists in the table by using the following SQL statement.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Create a publication for this table by using the `CREATE PUBLICATION` statement, as follows.
```
CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
```
1. **On the subscriber Aurora PostgreSQL DB cluster**
1. Create the same `LogicalReplicationTest` table on the subscriber that you created on the publisher, as follows.
```
CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
```
1. Verify that this table is empty.
```
SELECT count(*) FROM LogicalReplicationTest;
```
1. Create a subscription to get the changes from the publisher. You need to use the following details about the publisher Aurora PostgreSQL DB cluster.
+ **host** – The publisher Aurora PostgreSQL DB cluster's writer DB instance.
+ **port** – The port on which the writer DB instance is listening. The default for PostgreSQL is 5432.
+ **dbname** – The name of the database.
```
CREATE SUBSCRIPTION testsub CONNECTION
'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password'
PUBLICATION testpub;
```
**Note**
Specify a password other than the prompt shown here as a security best practice.
After the subscription is created, a logical replication slot is created at the publisher.
1. To verify for this example that the initial data is replicated on the subscriber, use the following SQL statement on the subscriber database.
```
SELECT count(*) FROM LogicalReplicationTest;
```
Any further changes on the publisher are replicated to the subscriber.
Logical replication affects performance. We recommend that you turn off logical replication after your replication tasks are complete.
# Example: Logical replication using Aurora PostgreSQL and AWS Database Migration Service
You can use the AWS Database Migration Service (AWS DMS) to replicate a database or a portion of a database. Use AWS DMS to migrate your data from an Aurora PostgreSQL database to another open source or commercial database. For more information about AWS DMS, see the [AWS Database Migration Service User Guide](https://docs.aws.amazon.com/dms/latest/userguide/).
The following example shows how to set up logical replication from an Aurora PostgreSQL database as the publisher and then use AWS DMS for migration. This example uses the same publisher and subscriber that were created in [Example: Using logical replication with Aurora PostgreSQL DB clusters](AuroraPostgreSQL.Replication.Logical.PostgreSQL-Example.md).
To set up logical replication with AWS DMS, you need details about your publisher and subscriber from Amazon RDS. In particular, you need details about the publisher's writer DB instance and the subscriber's DB instance.
Get the following information for the publisher's writer DB instance:
+ The virtual private cloud (VPC) identifier
+ The subnet group
+ The Availability Zone (AZ)
+ The VPC security group
+ The DB instance ID
Get the following information for the subscriber's DB instance:
+ The DB instance ID
+ The source engine
**To use AWS DMS for logical replication with Aurora PostgreSQL**
1. Prepare the publisher database to work with AWS DMS.
To do this, PostgreSQL 10.x and later databases require that you apply AWS DMS wrapper functions to the publisher database. For details on this and later steps, see the instructions in [Using PostgreSQL version 10.x and later as a source for AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10) in the *AWS Database Migration Service User Guide.*
1. Sign in to the AWS Management Console and open the AWS DMS console at [https://console.aws.amazon.com/dms/v2](https://console.aws.amazon.com/dms/v2). At top right, choose the same AWS Region in which the publisher and subscriber are located.
1. Create an AWS DMS replication instance.
Choose values that are the same as for your publisher's writer DB instance. These include the following settings:
+ For **VPC**, choose the same VPC as for the writer DB instance.
+ For **Replication Subnet Group**, choose a subnet group with the same values as the writer DB instance. Create a new one if necessary.
+ For **Availability zone**, choose the same zone as for the writer DB instance.
+ For **VPC Security Group**, choose the same group as for the writer DB instance.
1. Create an AWS DMS endpoint for the source.
Specify the publisher as the source endpoint by using the following settings:
+ For **Endpoint type**, choose **Source endpoint**.
+ Choose **Select RDS DB Instance**.
+ For **RDS Instance**, choose the DB identifier of the publisher's writer DB instance.
+ For **Source engine**, choose **postgres**.
1. Create an AWS DMS endpoint for the target.
Specify the subscriber as the target endpoint by using the following settings:
+ For **Endpoint type**, choose **Target endpoint**.
+ Choose **Select RDS DB Instance**.
+ For **RDS Instance**, choose the DB identifier of the subscriber DB instance.
+ Choose a value for **Source engine**. For example, if the subscriber is an RDS PostgreSQL database, choose **postgres**. If the subscriber is an Aurora PostgreSQL database, choose **aurora-postgresql**.
1. Create an AWS DMS database migration task.
You use a database migration task to specify what database tables to migrate, to map data using the target schema, and to create new tables on the target database. At a minimum, use the following settings for **Task configuration**:
+ For **Replication instance**, choose the replication instance that you created in an earlier step.
+ For **Source database endpoint**, choose the publisher source that you created in an earlier step.
+ For **Target database endpoint**, choose the subscriber target that you created in an earlier step.
The rest of the task details depend on your migration project. For more information about specifying all the details for DMS tasks, see [Working with AWS DMS tasks](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.html) in the *AWS Database Migration Service User Guide.*
After AWS DMS creates the task, it begins migrating data from the publisher to the subscriber.
# Configuring IAM authentication for logical replication connections
Starting with Aurora PostgreSQL versions 11 and higher, you can use AWS Identity and Access Management (IAM) authentication for replication connections. This feature enhances security by allowing you to manage database access using IAM roles instead of passwords. It works at the cluster level and follows the same security model as standard IAM authentication.
IAM authentication for replication connections is an opt-in feature. To enable it, set the `rds.iam_auth_for_replication` parameter to `1` in your DB cluster parameter group. As this is a dynamic parameter, your DB cluster doesn't need to restart, enabling you to leverage IAM authentication with existing workloads without downtime. Before enabling this feature, you must meet the [Prerequisites](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites) listed below.
## Prerequisites
To use IAM authentication for replication connections, you need to meet all of the following requirements:
+ Your Aurora PostgreSQL DB cluster must be version 11 or later.
+ On your publisher Aurora PostgreSQL DB cluster:
+ Enable IAM database authentication.
For more information, see [Enabling and disabling IAM database authentication](UsingWithRDS.IAMDBAuth.Enabling.md).
+ Enable logical replication by setting the `rds.logical_replication` parameter to `1`.
For more information, see [Setting up logical replication for your Aurora PostgreSQL DB cluster](AuroraPostgreSQL.Replication.Logical.Configure.md).
In logical replication, the publisher is the source Aurora PostgreSQL DB cluster that sends data to subscriber clusters. For more information, see [Overview of PostgreSQL logical replication with Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.Logical.html).
**Note**
Both IAM authentication and logical replication must be enabled on your publisher Aurora PostgreSQL DB cluster. If either one isn't enabled, you can't use IAM authentication for replication connections.
## Enabling IAM authentication for replication connections
Complete the following steps to enable IAM authentication for replication connection.
1. Verify that your Aurora PostgreSQL DB cluster meets all prerequisites for IAM authentication with replication connections. For details, see [Prerequisites](#AuroraPostgreSQL.Replication.Logical.IAM-auth-prerequisites).
1. Configure the `rds.iam_auth_for_replication` parameter by modifying your DB cluster parameter group:
+ Set the `rds.iam_auth_for_replication` parameter to `1`. This dynamic parameter doesn't require a reboot.
1. Connect to your database and grant the necessary roles to your replication user:
The following SQL commands grant the necessary roles to enable IAM authentication for replication connections:
```
-- Grant IAM authentication role
GRANT rds_iam TO replication_user_name;
-- Grant replication privileges
ALTER USER replication_user_name WITH REPLICATION;
```
After you complete these steps, the specified user must use IAM authentication for replication connections.
**Important**
When you enable the feature, users with both `rds_iam` and `rds_replication` roles must use IAM authentication for replication connections. This applies whether the roles are assigned directly to the user or inherited through other roles.
## Disabling IAM authentication for replication connections
You can disable IAM authentication for replication connections by using any of the following methods:
+ Set the `rds.iam_auth_for_replication` parameter to `0` in your DB cluster parameter group
+ Alternatively, you can disable either of these features on your Aurora PostgreSQL DB cluster:
+ Disable logical replication by setting the `rds.logical_replication` parameter to `0`
+ Disable IAM authentication
When you disable the feature, replication connections can use database passwords for authentication if configured.
**Note**
Replication connections for users without the `rds_iam` role can use password authentication even when the feature is enabled.
## Limitations and considerations
The following limitations and considerations apply when using IAM authentication for replication connections.
+ IAM authentication for replication connections is only available for Aurora PostgreSQL versions 11 and higher.
+ The publisher must support IAM authentication for replication connections.
+ The IAM authentication token expires after 15 minutes by default. You might need to refresh long-running replication connections before the token expires.
# Local write forwarding in Aurora PostgreSQL
*Local (in-cluster) write forwarding* allows your applications to issue read/write transactions directly on an Aurora Replica. The write commands are then forwarded to the writer DB instance to be committed. You can use local write forwarding for your applications that have occasional writes and require *read-after-write consistency*, which is the ability to read the latest write in a transaction.
Without write forwarding, your applications must fully split all read and write traffic, maintaining two sets of database connections to send the traffic to the appropriate endpoint. Read replicas receive updates asynchronously from the writer instance. In addition, because replication lag can differ among read replicas, achieving global read consistency across all replicas is difficult. You must transact any reads requiring read-after-write consistency on the writer database instance. Alternatively, you would need to develop complex custom application logic to take advantage of multiple read replicas for scalability while ensuring consistency.
With write forwarding, you avoid the need to split those transactions or send them exclusively to the writer instance. You also don't have to develop complex application logic to achieve *read-after-write consistency* consistency.
Local write forwarding is available in every Region where Aurora PostgreSQL is available. It is supported in the following Aurora PostgreSQL versions:
+ 16.4 and higher 16 versions
+ 15.8 and higher 15 versions
+ 14.13 and higher 14 versions
Local write forwarding is used to forward writes from in-Region replicas. To forward writes from a global replica, see [Using write forwarding in an Amazon Aurora global database](aurora-global-database-write-forwarding.md).
**Topics**
+ [Limitations and considerations of local write forwarding in Aurora PostgreSQL](aurora-postgresql-write-forwarding-limitations.md)
+ [Configuring Aurora PostgreSQL for Local write forwarding](aurora-postgresql-write-forwarding-configuring.md)
+ [Working with local write forwarding for Aurora PostgreSQL](aurora-postgresql-write-forwarding-understanding.md)
+ [Monitoring local write forwarding in Aurora PostgreSQL](aurora-postgresql-write-forwarding-monitoring.md)
# Limitations and considerations of local write forwarding in Aurora PostgreSQL
The following limitations currently apply to local write forwarding in Aurora PostgreSQL:
+ Local write forwarding is not supported with RDS Proxy.
+ Certain statements aren't allowed or can produce stale results when you use them in Aurora PostgreSQL with write forwarding. In addition, user defined functions and user defined procedures aren't supported. Thus, the `EnableLocalWriteForwarding` setting is turned off by default for DB clusters. Before turning it on, check to make sure that your application code isn't affected by any of these restrictions.
+ The following kinds of SQL statements aren't supported with write forwarding:
**Note**
These statements can be implicitly used by you in your application or inferred by the PostgreSQL protocol. For example, PL/SQL exception handling can result in the use of SAVEPOINT, which is not a supported statement.
+ `ANALYZE`
+ `CLUSTER`
+ `COPY`
+ Cursors – Cursors aren't supported, so make sure to close them before using local write forwarding.
+ Data definition language (DDL) statements
+ `GRANT`\$1`REVOKE`\$1`REASSIGN OWNED`\$1`SECURITY LABEL`
+ `LISTEN / NOTIFY`
+ `LOCK`
+ `SAVEPOINT`
+ `SELECT INTO`
+ `SET CONSTRAINTS`
+ Sequence updates: `nextval()`, `setval()`
+ `TRUNCATE`
+ Two-phase commit commands: `PREPARE TRANSACTION`, `COMMIT PREPARED`, `ROLLBACK PREPARED`
+ User defined functions and user defined procedures.
+ `VACUUM`
You can consider using the following SQL statements with write forwarding:
+ A DML statement might consist of multiple parts, such as an `INSERT ... SELECT` statement or a `DELETE ... WHERE` statement. In this case, the entire statement is forwarded to the writer DB instance and run there.
+ Data manipulation language (DML) statements, such as `INSERT`, `DELETE`, and `UPDATE`.
+ `EXPLAIN` statements with the statements in this list.
+ `PREPARE` and `EXECUTE` statements.
+ `SELECT FOR { UPDATE | NO KEY UPDATE | SHARE | KEY SHARE }` statements.
# Configuring Aurora PostgreSQL for Local write forwarding
Using the following sections, you can enable local write forwarding for your Amazon Aurora PostgreSQL DB cluster, configuring consistency levels, and managing transactions with write forwarding.
## Enabling local write forwarding
By default, local write forwarding isn't enabled for Aurora PostgreSQL DB clusters. You enable local write forwarding at the cluster level, not at the instance level.
### Console
Using the AWS Management Console, select the **Turn on local write forwarding** check box under **Read replica write forwarding** when you create or modify a DB cluster.
### AWS CLI
To enable local write forwarding with the AWS CLI, use the `--enable-local-write-forwarding` option. This option works when you create a new DB cluster using the `create-db-cluster` command. It also works when you modify an existing DB cluster using the `modify-db-cluster` command. You can disable local write forwarding by using the `--no-enable-local-write-forwarding` option with these same CLI commands.
The following example creates an Aurora PostgreSQL DB cluster with local write forwarding enabled.
```
aws rds create-db-cluster \
--db-cluster-identifier write-forwarding-test-cluster \
--enable-local-write-forwarding \
--engine aurora-postgresql \
--engine-version 16.4 \
--master-username myuser \
--master-user-password mypassword \
--backup-retention 1
```
You then create writer and reader DB instances so that you can use write forwarding. For more information, see [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md).
### RDS API
To enable local write forwarding using the Amazon RDS API, set the `EnableLocalWriteForwarding` parameter to `true`. This parameter works when you create a new DB cluster using the `CreateDBCluster` operation. It also works when you modify an existing DB cluster using the `ModifyDBCluster` operation. You can disable local write forwarding by setting the `EnableLocalWriteForwarding` parameter to `false`.
### Enabling local write forwarding for database sessions
The `apg_write_forward.consistency_mode` parameter is a DB parameter and DB cluster parameter that enables write forwarding. You can specify `SESSION`, `EVENTUAL`, `GLOBAL`, or `OFF` for the read consistency level. To learn more about consistency levels, see [Consistency and isolation for local write forwarding in Aurora PostgreSQL](#aurora-postgresql-write-forwarding-isolation).
The following rules apply to this parameter:
+ The default value is `SESSION`.
+ Local write forwarding is available only if you set `apg_write_forward.consistency_mode` to `EVENTUAL`, `SESSION`, or `GLOBAL`. This parameter is relevant only in reader instances of DB clusters that have local write forwarding enabled.
+ Setting the value to `OFF` disables local write forwarding in the session.
## Consistency and isolation for local write forwarding in Aurora PostgreSQL
You can control the degree of read consistency on a read replica. You can adjust the read consistency level to ensure that all forwarded write operations from your session are visible in the read replica before any subsequent queries. You can also use this setting to ensure that queries on the read replica always see the most current updates from the writer DB instance. This is so even for those submitted by other sessions or other clusters. To specify this type of behavior for your application, you choose the appropriate value for the session-level parameter `apg_write_forward.consistency_mode`. The `apg_write_forward.consistency_mode` parameter has an effect only on read replicas that have local write forwarding enabled.
**Note**
For the `apg_write_forward.consistency_mode` parameter, you can specify the value `SESSION`, `EVENTUAL`, `GLOBAL`, or `OFF`. By default, the value is set to `SESSION`. Setting the value to `OFF` disables write forwarding.
As you increase the consistency level, your application spends more time waiting for changes to be propagated to read replicas. You can choose the balance between lower latency and ensuring that changes made in other locations are fully available before your queries run.
With each available consistency mode setting, the effect is as follows:
+ `SESSION` – A session on a read replica that uses local write forwarding see the results of all changes made in that session. The changes are visible regardless of whether the transaction is committed. If necessary, the query waits for the results of forwarded write operations to be replicated to the current reader DB instance. It doesn't wait for updated results from write operations performed in other sessions within the current DB cluster.
+ `EVENTUAL` – A session on a read replica that uses local write forwarding might see data that is slightly stale due to replication lag. Results of write operations in the same session aren't visible until the write operation is performed on the writer DB instance and replicated to the read replica. The query doesn't wait for the updated results to be available. Thus, it might retrieve the older data or the updated data, depending on the timing of the statements and the amount of replication lag.
+ `GLOBAL` – A session on a read replica sees changes made by that session. It also sees all committed changes from both the writer DB instance and other read replicas. Each query might wait for a period that varies depending on the amount of session lag. The query proceeds when the read replica is up-to-date with all committed data from the writer DB instance, as of the time that the query began.
**Note**
The global consistency mode impacts the latency of queries executed within a session. It will perform a wait even when the session has not sent any write queries.
+ `OFF` – Local write forwarding is disabled.
In sessions that use write forwarding, you can use the `REPEATABLE READ` and `READ COMMITTED` isolation levels. However, the `SERIALIZABLE` isolation level isn't supported.
For more information about all the parameters involved with write forwarding, see [Default parameter settings for write forwarding](aurora-postgresql-write-forwarding-understanding.md#aurora-postgresql-write-forwarding-params).
## Transaction access modes with write forwarding
If the transaction access mode is set to read only, local write forwarding isn't used. You can set the access mode to read write only while you’re connected to a DB cluster and session that has local write forwarding enabled.
For more information on the transaction access modes, see [SET TRANSACTION](https://www.postgresql.org/docs/current/sql-set-transaction.html).
# Working with local write forwarding for Aurora PostgreSQL
Using the following sections, you can check if a database cluster has local write forwarding enabled, view compatibility considerations, and see configurable parameters and authentication setup. This information equips you with the details to utilize local write forwarding feature in Aurora PostgreSQL effectively.
**Note**
When a writer instance in a cluster using local write forwarding is restarted, any active, forwarded transactions and queries on reader instances using local write forwarding are automatically closed. After the writer instance is available again, you can retry these transactions.
## Checking if a DB cluster has local write forwarding enabled
To determine that you can use local write forwarding in a DB cluster, confirm that the cluster has the attribute `LocalWriteForwardingStatus` set to `enabled`.
In the AWS Management Console, on the **Configuration** tab of the details page for the cluster, you see the status **Enabled** for **Local read replica write forwarding**.
To see the status of the local write forwarding setting for all of your clusters, run the following AWS CLI command.
**Example**
```
aws rds describe-db-clusters \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}'
[
{
"LocalWriteForwardingStatus": "enabled",
"DBClusterIdentifier": "write-forwarding-test-cluster-1"
},
{
"LocalWriteForwardingStatus": "disabled",
"DBClusterIdentifier": "write-forwarding-test-cluster-2"
},
{
"LocalWriteForwardingStatus": "requested",
"DBClusterIdentifier": "test-global-cluster-2"
},
{
"LocalWriteForwardingStatus": "null",
"DBClusterIdentifier": "aurora-postgresql-v2-cluster"
}
]
```
A DB cluster can have the following values for `LocalWriteForwardingStatus`:
+ `disabled` – Local write forwarding is disabled.
+ `disabling` – Local write forwarding is in the process of being disabled.
+ `enabled` – Local write forwarding is enabled.
+ `enabling` – Local write forwarding is in the process of being enabled.
+ `null` – Local write forwarding isn't available for this DB cluster.
+ `requested` – Local write forwarding has been requested, but is not yet active.
## Default parameter settings for write forwarding
The Aurora cluster parameter groups include settings for the local write forwarding feature. Because these are cluster parameters, all DB instances in each cluster have the same values for these variables. Details about these parameters are summarized in the following table, with usage notes after the table.
| Parameter | Scope | Type | Default value | Valid values |
| --- | --- | --- | --- | --- |
| apg\$1write\$1forward.connect\$1timeout | Session | seconds | 30 | 0–2147483647 |
| apg\$1write\$1forward.consistency\$1mode | Session | enum | Session | SESSION, EVENTUAL, GLOBAL, and OFF |
| apg\$1write\$1forward.idle\$1in\$1transaction\$1session\$1timeout | Session | milliseconds | 86400000 | 0–2147483647 |
| apg\$1write\$1forward.idle\$1session\$1timeout | Session | milliseconds | 300000 | 0–2147483647 |
| apg\$1write\$1forward.max\$1forwarding\$1connections\$1percent | Global | int | 25 | 1–100 |
The `apg_write_forward.max_forwarding_connections_percent` parameter is the upper limit on database connection slots that can be used to handle queries forwarded from readers. It is expressed as a percentage of the `max_connections` setting for the writer DB instance. For example, if `max_connections` is `800` and `apg_write_forward.max_forwarding_connections_percent` is `10`, then the writer allows a maximum of 80 simultaneous forwarded sessions. These connections come from the same connection pool managed by the `max_connections` setting. This setting applies only on the writer DB instance when the cluster has local write forwarding enabled.
Use the following settings to control local write forwarding requests:
+ `apg_write_forward.consistency_mode` – A session-level parameter that controls the degree of read consistency on a read replica. Valid values are `SESSION`, `EVENTUAL`, `GLOBAL`, or `OFF`. By default, the value is set to `SESSION`. Setting the value to `OFF` disables local write forwarding in the session. To learn more about consistency levels, see [Consistency and isolation for local write forwarding in Aurora PostgreSQL](aurora-postgresql-write-forwarding-configuring.md#aurora-postgresql-write-forwarding-isolation). This parameter is relevant only in reader instances that have local write forwarding enabled.
+ `apg_write_forward.connect_timeout` – The maximum number of seconds the read replica waits when establishing a connection to the writer DB instance before giving up. A value of `0` means to wait indefinitely.
+ `apg_write_forward.idle_in_transaction_session_timeout` – The number of milliseconds the writer DB instance waits for activity on a connection that's forwarded from a read replica that has an open transaction before closing it. If the session remains idle in transaction beyond this period, Aurora terminates the session. A value of `0` disables the timeout.
+ `apg_write_forward.idle_session_timeout` – The number of milliseconds the writer DB instance waits for activity on a connection that's forwarded from a read replica before closing it. If the session remains idle beyond this period, Aurora terminates the session. A value of `0` disables the timeout.
## rdswriteforwarduser
The `rdswriteforwarduser` is a user that we will use to establish a connection between the read replica and the writer DB instance.
**Note**
`rdswriteforwarduser` inherits its CONNECT privileges to customer databases via the PUBLIC role. If the privileges for the PUBLIC role are revoked, you will need to GRANT CONNECT privileges for the databases you need to forward writes to.
# Monitoring local write forwarding in Aurora PostgreSQL
Using the following sections you can monitor local write forwarding in Aurora PostgreSQL clusters, including relevant CloudWatch metrics and wait events to track performance and identify potential issues.
## Amazon CloudWatch metrics and Aurora PostgreSQL status variables for write forwarding
The following Amazon CloudWatch metrics apply to the writer DB instances when you use write forwarding on one or more read replicas.
| CloudWatch Metric | Units and description |
| --- | --- |
| `AuroraLocalForwardingWriterDMLThroughput` | Count (per second). Number of forwarded DML statements processed each second by this writer DB instance. |
| `AuroraLocalForwardingWriterOpenSessions` | Count. Number of open sessions on this writer DB instance processing forwarded queries. |
| `AuroraLocalForwardingWriterTotalSessions` | Count. Total number of forwarded sessions on this writer DB instance. |
The following CloudWatch metrics apply to each read replica. These metrics are measured on each reader DB instance in the DB cluster with local write forwarding enabled.
| CloudWatch Metric | Unit and description |
| --- | --- |
| `AuroraForwardingReplicaCommitThroughput` | Count (per second). Number of commits in sessions forwarded by this replica each second. |
| `AuroraForwardingReplicaDMLLatency` | Milliseconds. Average response time in milliseconds of forwarded DMLs on replica. |
| `AuroraForwardingReplicaDMLThroughput` | Count (per second). Number of forwarded DML statements processed on this replica each second. |
| `AuroraForwardingReplicaErrorSessionsLimit` | Count. Number of sessions rejected by the writer DB instance because the limit for max connections or max write forward connections was reached. |
| `AuroraForwardingReplicaOpenSessions` | Count. The number of sessions that are using local write forwarding on a replica instance. |
| `AuroraForwardingReplicaReadWaitLatency` | Milliseconds. Average wait time in milliseconds that the replica waits to be consistent with the LSN of the writer DB instance. The degree to which the reader DB instance waits depends on the apg\$1write\$1forward.consistency\$1mode setting. For information about this setting, see [Configuration parameters for write forwarding in Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg). |
## Wait events for local write forwarding in Aurora PostgreSQL
Amazon Aurora generates the following wait events when you use write forwarding with Aurora PostgreSQL.
**Topics**
+ [IPC:AuroraWriteForwardConnect](#apg-waits.ipcaurorawriteforwardconnect)
+ [IPC:AuroraWriteForwardConsistencyPoint](#apg-waits.ipcaurorawriteforwardconsistencypoint)
+ [IPC:AuroraWriteForwardExecute](#apg-waits.ipc:aurorawriteforwardexecute)
+ [IPC:AuroraWriteForwardGetGlobalConsistencyPoint](#apg-waits.ipc:aurorawriteforwardgetglobalconsistencypoint)
+ [IPC:AuroraWriteForwardXactAbort](#apg-waits.ipc:aurorawriteforwardxactabort)
+ [IPC:AuroraWriteForwardXactCommit](#apg-waits.ipc:aurorawriteforwardxactcommit)
+ [IPC:AuroraWriteForwardXactStart](#apg-waits.ipc:aurorawriteforwardxactstart)
### IPC:AuroraWriteForwardConnect
The `IPC:AuroraWriteForwardConnect` event occurs when a backend process on the read replica is waiting for a connection to the writer DB instance to be opened.
**Likely causes of increased waits**
This event increases as the number of connection attempts from a read replica to the writer node increases.
**Actions**
Reduce the number of simultaneous connections from a read replica to the writer node.
### IPC:AuroraWriteForwardConsistencyPoint
The `IPC:AuroraWriteForwardConsistencyPoint` event describes how long a query from a node on the read replica will wait for the results of forwarded write operations to be replicated to the current Region. This event is only generated if the session-level parameter `apg_write_forward.consistency_mode` is set to one of the following:
+ `SESSION` – queries on a read replica wait for the results of all changes made in that session.
+ `GLOBAL` – queries on a read replica wait for the results of changes made by that session, plus all committed changes from both the writer DB instance and read replica.
For more information about the `apg_write_forward.consistency_mode` parameter settings, see [Configuration parameters for write forwarding in Aurora PostgreSQL](aurora-global-database-write-forwarding-apg.md#aurora-global-database-write-forwarding-params-apg).
**Likely causes of increased waits**
Common causes for longer wait times include the following:
+ Increased replica lag, as measured by the Amazon CloudWatch `ReplicaLag` metric. For more information about this metric, see [Monitoring Aurora PostgreSQL replication](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Monitoring).
+ Increased load on the writer DB instance or read replica.
**Actions**
Change your consistency mode, depending on your application's requirements.
### IPC:AuroraWriteForwardExecute
The `IPC:AuroraWriteForwardExecute` event occurs when a backend process on the read replica is waiting for a forwarded query to complete and obtain results from the writer node of the DB cluster.
**Likely causes of increased waits**
Common causes for increased waits include the following:
+ Fetching a large number of rows from the writer node.
+ Increased network latency between the writer node and read replica increases the time it takes the read replica to receive data from the writer node.
+ Increased load on the read replica can delay transmission of the query request from the read replica to the writer node.
+ Increased load on the writer node can delay transmission of data from the writer node to the read replica.
**Actions**
We recommend different actions depending on the causes of your wait event.
+ Optimize queries to retrieve only necessary data.
+ Optimize data manipulation language (DML) operations to only modify necessary data.
+ If the read replica or writer node is constrained by CPU or network bandwidth, consider changing it to an instance type with more CPU capacity or more network bandwidth.
### IPC:AuroraWriteForwardGetGlobalConsistencyPoint
The `IPC:AuroraWriteForwardGetGlobalConsistencyPoint` event occurs when a backend process on the read replica that's using the GLOBAL consistency mode is waiting to obtain the global consistency point from the writer node before executing a query.
**Likely causes of increased waits**
Common causes for increased waits include the following:
+ Increased network latency between the read replica and writer node increases the time it takes the read replica to receive data from the writer node.
+ Increased load on the read replica can delay transmission of the query request from the read replica to the writer node.
+ Increased load on the writer node can delay transmission of data from the writer node to the read replica.
**Actions**
We recommend different actions depending on the causes of your wait event.
+ Change your consistency mode, depending on your application's requirements.
+ If the read replica or writer node is constrained by CPU or network bandwidth, consider changing it to an instance type with more CPU capacity or more network bandwidth.
### IPC:AuroraWriteForwardXactAbort
The `IPC:AuroraWriteForwardXactAbort` event occurs when a backend process on the read replica is waiting for the result of a remote cleanup query. Cleanup queries are issued to return the process to the appropriate state after a write-forwarded transaction is aborted. Amazon Aurora performs them either because an error was found or because an user issued an explicit `ABORT` command or cancelled a running query.
**Likely causes of increased waits**
Common causes for increased waits include the following:
+ Increased network latency between the read replica and writer node increases the time it takes the read replica to receive data from the writer node.
+ Increased load on the read replica can delay transmission of the cleanup query request from the read replica to the writer node.
+ Increased load on the writer node can delay transmission of data from the writer node to the read replica.
**Actions**
We recommend different actions depending on the causes of your wait event.
+ Investigate the cause of the aborted transaction.
+ If the read replica or writer DB instance is constrained by CPU or network bandwidth, consider changing it to an instance type with more CPU capacity or more network bandwidth.
### IPC:AuroraWriteForwardXactCommit
The `IPC:AuroraWriteForwardXactCommit` event occurs when a backend process on the read replica is waiting for the result of a forwarded commit transaction command.
**Likely causes of increased waits**
Common causes for increased waits include the following:
+ Increased network latency between the read replica and writer node increases the time it takes the read replica to receive data from the writer node.
+ Increased load on the read replica can delay transmission of the query request from the read replica to the writer node.
+ Increased load on the writer node can delay transmission of data from the writer node to the read replica.
**Actions**
If the read replica or writer node is constrained by CPU or network bandwidth, consider changing it to an instance type with more CPU capacity or more network bandwidth.
### IPC:AuroraWriteForwardXactStart
The `IPC:AuroraWriteForwardXactStart` event occurs when a backend process on the read replica is waiting for the result of a forwarded start transaction command.
**Likely causes of increased waits**
Common causes for increased waits include the following:
+ Increased network latency between the read replica and writer node increases the time it takes the read replica to receive data from the writer node.
+ Increased load on the read replica can delay transmission of the query request from the read replica to the writer node.
+ Increased load on the writer node can delay transmission of data from the writer node to the read replica.
**Actions**
If the read replica or writer node is constrained by CPU or network bandwidth, consider changing it to an instance type with more CPU capacity or more network bandwidth.
# Using Aurora PostgreSQL as a Knowledge Base for Amazon Bedrock
You can use an Aurora PostgreSQL DB cluster as a Knowledge Base for Amazon Bedrock. For more information, see [Create a vector store in Amazon Aurora](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-setup.html). A Knowledge Base automatically takes unstructured text data stored in an Amazon S3 bucket, converts it to text chunks and vectors, and stores it in a PostgreSQL database. With the generative AI applications, you can use Agents for Amazon Bedrock to query the data stored in the Knowledge Base and use the results of those queries to augment answers provided by foundational models. This workflow is called Retrieval Augmented Generation (RAG). For more information on RAG, see [Retrieval Augmented Generation (RAG)](https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-foundation-models-customize-rag.html).
For detailed information about using Aurora PostgreSQL to build generative AI applications using RAG, see this [blog post](https://aws.amazon.com/blogs/database/build-generative-ai-applications-with-amazon-aurora-and-knowledge-bases-for-amazon-bedrock/).
**Topics**
+ [Prerequisites](#AuroraPostgreSQL.VectorDB.Prereq)
+ [Preparing Aurora PostgreSQL to be used as a Knowledge Base for Amazon Bedrock](#AuroraPostgreSQL.VectorDB.PreparingKB)
+ [Creating a Knowledge Base in the Bedrock console](#AuroraPostgreSQL.VectorDB.CreatingKB)
+ [Quick create an Aurora PostgreSQL Knowledge Base for Amazon Bedrock](AuroraPostgreSQL.quickcreatekb.md)
## Prerequisites
Familiarize yourself with the following prerequisites to use Aurora PostgreSQL cluster as a Knowledge Base for Amazon Bedrock. At a high level, you need to configure the following services for use with Bedrock:
+ Amazon Aurora PostgreSQL DB cluster created in any of the following versions:
+ 16.1 and all higher versions
+ 15.4 and higher versions
+ 14.9 and higher versions
+ 13.12 and higher versions
+ 12.16 and higher versions
**Note**
You must enable the `pgvector` extension in your target database and use version 0.5.0 or higher. For more information, see [pgvector v0.5.0 with HNSW indexing](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-aurora-postgresql-pgvector-v0-5-0-hnsw-indexing/).
+ RDS Data API
+ A user managed in AWS Secrets Manager. For more information, see [Password management with Amazon Aurora and AWS Secrets Manager](rds-secrets-manager.md).
## Preparing Aurora PostgreSQL to be used as a Knowledge Base for Amazon Bedrock
Follow the steps explained in the below sections to prepare Aurora PostgreSQL to be used as a Knowledge Base for Amazon Bedrock.
### Creating and configuring Aurora PostgreSQL
To configure Amazon Bedrock with an Aurora PostgreSQL DB cluster, you must first create an Aurora PostgreSQL DB cluster and take note of the important fields for configuring it with Amazon Bedrock. For more information about creating Aurora PostgreSQL DB cluster, see [Creating and connecting to an Aurora PostgreSQL DB cluster](CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.md).
+ Enable Data API while creating Aurora PostgreSQL DB cluster. For more information on the versions supported, see [Using the Amazon RDS Data API](data-api.md).
+ Make sure to note down the Amazon Resource Names (ARN) of your Aurora PostgreSQL DB cluster. You'll need it to configure the DB cluster for use with Amazon Bedrock. For more information, see [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Tagging.ARN.html).
### Connecting to a database and installing pgvector
You can connect to Aurora PostgreSQL using any of the connection utilities. For more detailed information on these utilities, see [Connecting to an Amazon Aurora PostgreSQL DB cluster](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL). Alternatively, you can use the RDS console query editor to run the queries. You need an Aurora DB cluster with the RDS Data API enabled to use the query editor.
1. Log in to the database with your master user and set up pgvector. Use the following command if the extension is not installed:
```
CREATE EXTENSION IF NOT EXISTS vector;
```
Use `pgvector` 0.5.0 and higher version that supports HNSW indexing. For more information, see [pgvector v0.5.0 with HNSW indexing](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-aurora-postgresql-pgvector-v0-5-0-hnsw-indexing/).
1. Use the following command to check the version of the `pg_vector` installed:
```
SELECT extversion FROM pg_extension WHERE extname='vector';
```
### Setting up database objects and privileges
1. Create a specific schema that Bedrock can use to query the data. Use the following command to create a schema:
```
CREATE SCHEMA bedrock_integration;
```
1. Create a new role that Bedrock can use to query the database. Use the following command to create a new role:
```
CREATE ROLE bedrock_user WITH PASSWORD 'password' LOGIN;
```
**Note**
Make a note of this password as you will need it later to create a Secrets Manager password.
If you are using `psql` client, then use the following commands to create a new role:
```
CREATE ROLE bedrock_user LOGIN;
\PASSWORD password;
```
1. Grant the `bedrock_user` permissions to manage the `bedrock_integration` schema. This will provide the ability to create tables or indexes within the schema.
```
GRANT ALL ON SCHEMA bedrock_integration to bedrock_user;
```
1. Login as the `bedrock_user` and create a table in the `bedrock_integration schema`.
```
CREATE TABLE bedrock_integration.bedrock_kb (id uuid PRIMARY KEY, embedding vector(n), chunks text, metadata json, custom_metadata jsonb);
```
This command will create the `bedrock_kb` table in the `bedrock_integration` schema with Titan embeddings.
Replace n in the `vector(n)` data type with the appropriate dimension for the embedding model you are using. Use the recommendations below to help select your dimensions:
+ For the Titan v2 model, use `vector(1024)`, or `vector(512)`, or `vector (256)`. To learn more, see [Amazon Titan Embeddings Text](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-titan-embed-text.html).
+ For the Titan v1.2 model, use `vector(1536)`. To learn more, see [Amazon Titan Multimodal Embeddings G1](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-titan-embed-mm.html).
+ For the Cohere Embed model, use `vector(1024)`. To learn more, see [Cohere Embed models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-embed.html).
+ For the Cohere Embed Multilingual v3, use `vector(1024)`.
The first four columns are mandatory. For metadata handling, Bedrock writes data from your metadata files to the `custom_metadata` column. We recommend creating this column if you plan to use metadata and filtering. If you don't create a `custom_metadata` column, add individual columns for each metadata attribute in your table before you begin ingestion. For more information, see [Configure and customize queries and response generation](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-config.html).
1. Follow these steps to create the required indexes that Bedrock uses to query your data:
+ Create an index with the cosine operator which the bedrock can use to query the data.
```
CREATE INDEX ON bedrock_integration.bedrock_kb USING hnsw (embedding vector_cosine_ops);
```
+ We recommend you to set the value of `ef_construction` to 256 for `pgvector` 0.6.0 and higher version that use parallel index building.
```
CREATE INDEX ON bedrock_integration.bedrock_kb USING hnsw (embedding vector_cosine_ops) WITH (ef_construction=256);
```
+ Create an index which Bedrock can use to query the text data.
```
CREATE INDEX ON bedrock_integration.bedrock_kb USING gin (to_tsvector('simple', chunks));
```
+ If you created a column for custom metadata, create an index which Bedrock can use to query the metadata.
```
CREATE INDEX ON bedrock_integration.bedrock_kb USING gin (custom_metadata);
```
### Create a secret in Secrets Manager
Secrets Manager lets you store your Aurora credentials so that they can be securely transmitted to applications. If you didn't choose the AWS secrets manager option when creating Aurora PostgreSQL DB cluster, you can create a secret now. For more information about creating AWS Secrets Manager database secret, see [AWS Secrets Manager database secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_database_secret.html).
## Creating a Knowledge Base in the Bedrock console
While preparing Aurora PostgreSQL to be used as the vector store for a Knowledge Base, you must gather the following details that you need to provide to Amazon Bedrock console.
+ **Amazon Aurora DB cluster ARN** – The ARN of your DB cluster.
+ **Secret ARN** – The ARN of the AWS Secrets Manager key for your DB cluster.
+ **Database name** – The name of your database. For example, you can use the default database *postgres*.
+ **Table name** – We recommend you to provide a schema qualified name while creating the table using the command similar to the following:
```
CREATE TABLE bedrock_integration.bedrock_kb;
```
This command will create the `bedrock_kb` table in the `bedrock_integration` schema.
+ When creating the table, make sure to configure it with the specified columns and data types. You can use your preferred column names instead of those listed in the table. Remember to take a note of the names you chose for reference during the Knowledge Base set up.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.VectorDB.html)
With these details, you can now create a Knowledge Base in the Bedrock console. For more detailed information on setting up a vector index and creating a Knowledge Base information, see [Create a vector store in Amazon Aurora](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-setup-rds.html) and [Create a vector store in Amazon Aurora](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html).
After adding Aurora as your Knowledge Base, you can now ingest your data sources for searching and querying. For more information, see [Ingest your data sources into the Knowledge Base](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-ingest.html).
# Quick create an Aurora PostgreSQL Knowledge Base for Amazon Bedrock
Amazon Bedrock's retrieval augmented generation (RAG) workflow relies on vector data stored in an Aurora PostgreSQL database to power content retrieval. Previously, setting up Aurora PostgreSQL as the vector data store for Bedrock Knowledge Bases was a multi-step process, requiring numerous manual actions across different user interfaces. This made it challenging for data scientists and developers to leverage Aurora for their Bedrock projects.
To improve the user experience, AWS has created a new CloudFormation-based quick create option that simplifies the setup process. With Aurora quick create, you can now provision a pre-configured Aurora PostgreSQL DB cluster as the vector store for your Amazon Bedrock Knowledge Bases with a single click.
**Topics**
+ [Supported regions and Aurora PostgreSQL versions](#AuroraPostgreSQL.quickcreatekb.avail)
+ [Understanding the quick create process](#AuroraPostgreSQL.quickcreatekb.using)
+ [Benefits of using Aurora quick create](#AuroraPostgreSQL.quickcreatekb.adv)
+ [Limitations of Aurora quick create process](#AuroraPostgreSQL.quickcreatekb.limit)
## Supported regions and Aurora PostgreSQL versions
The Aurora quick create option is available in all the AWS regions that support Amazon Bedrock Knowledge Bases. By default, it creates an Aurora PostgreSQL DB cluster with version 15.7. For more information about supported Regions, see [Supported models and regions for Amazon Bedrock Knowledge Bases](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-supported.html).
## Understanding the quick create process
The quick create process automatically provisions the following resources to set up an Amazon Aurora PostgreSQL database as the vector data store for your Bedrock Knowledge Base:
An Aurora PostgreSQL DB cluster in your account, configured with default settings.
+ ACUs (Aurora Capacity Units) are set from 0 to 16. This lets your vector store scale down to zero when not in use, saving on compute costs. The ACUs can be adjusted later in the Amazon RDS console.
+ (Hierarchical Navigable Small World) HNSW index using Euclidean distance as a similarity measure for the Bedrock vector embeddings stored in Aurora.
+ The DB instance is a serverless v2 instance.
+ The cluster is associated with the default VPC and subnets, and has the RDS Data API enabled.
+ The cluster admin credentials are managed by AWS Secrets Manager.
Besides the default settings, the following settings are set up for you. As you go through the process, you'll see screens that explains the workflow.
+ Seeding the Aurora cluster with the necessary database objects:
+ Create the pgvector extension, schema, role, and tables required for the Bedrock Knowledge Base.
+ Register a limited-privilege database user for Bedrock to interact with the cluster.
+ A progress banner will be displayed throughout the resource provisioning process, allowing you to track the status of the following sub-events:
+ Aurora cluster creation
+ Seeding the Aurora cluster
+ Knowledge Base creation
The banner stays visible until the knowledge base is fully created, even if you navigate away from the page and return.
+ You can click `View details` on the progress banner to see the status of each step. For more information about events during knowledge base creation, choose the CloudFormation link in the view details screen. Once the process is complete, your new Bedrock Knowledge Base will be ready to use.
+ The stack IDs for all the quick create resources can be found in the tags of the Bedrock Knowledge Base, should you need to reference them.
A Bedrock Knowledge Base, with the configuration to the newly provisioned Aurora cluster as the vector store is created.
## Benefits of using Aurora quick create
+ The CloudFormation-based quick create process significantly reduces the time and complexity required to use Aurora as the vector store.
+ Aurora offers excellent performance, vector scalability and cost benefits with the ability to scale to zero compute charges when not in use.
+ The quick create process streamlines the end-to-end experience, allowing you to easily create and configure your Bedrock Knowledge Bases using Aurora.
+ Customers can build upon CloudFormation template to customize the provisioning with their own configurations.
## Limitations of Aurora quick create process
+ With Aurora quick create option, the DB cluster is provisioned with default configurations. However, these default settings may not meet your specific requirements or intended use case. Quick create does not offer options to modify the configurations during the provisioning process. The configurations are set automatically to streamline the deployment experience. If you need to customize the Aurora DB cluster configuration, you can do so after the initial deployment by quick create in the Amazon RDS console.
+ While quick create flow simplifies the setup process, the time to create the Aurora DB cluster is still approximately 10 minutes, the same as a manual deployment. This is due to the time required to provision the Aurora infrastructure.
+ The quick create option is designed for experimentation and quick setup. The resources created through quick create may not be suitable for production use, and you won't be able to directly migrate them to a production environment in your VPC.
# Integrating Amazon Aurora PostgreSQL with other AWS services
Amazon Aurora integrates with other AWS services so that you can extend your Aurora PostgreSQL DB cluster to use additional capabilities in the AWS Cloud. Your Aurora PostgreSQL DB cluster can use AWS services to do the following:
+ Quickly collect, view, and assess performance for your Aurora PostgreSQL DB instances with Amazon RDS Performance Insights. Performance Insights expands on existing Amazon RDS monitoring features to illustrate your database's performance and help you analyze any issues that affect it. With the Performance Insights dashboard, you can visualize the database load and filter the load by waits, SQL statements, hosts, or users. For more information about Performance Insights, see [Monitoring DB load with Performance Insights on Amazon Aurora](USER_PerfInsights.md).
+ Configure your Aurora PostgreSQL DB cluster to publish log data to Amazon CloudWatch Logs. CloudWatch Logs provide highly durable storage for your log records. With CloudWatch Logs, you can perform real-time analysis of the log data, and use CloudWatch to create alarms and view metrics. For more information, see [Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md).
+ Import data from an Amazon S3 bucket to an Aurora PostgreSQL DB cluster, or export data from an Aurora PostgreSQL DB cluster to an Amazon S3 bucket. For more information, see [Importing data from Amazon S3 into an Aurora PostgreSQL DB cluster](USER_PostgreSQL.S3Import.md) and [Exporting data from an Aurora PostgreSQL DB cluster to Amazon S3](postgresql-s3-export.md).
+ Add machine learning-based predictions to database applications using the SQL language. Aurora machine learning uses a highly optimized integration between the Aurora database and the AWS machine learning (ML) services SageMaker AI and Amazon Comprehend. For more information, see [Using Amazon Aurora machine learning with Aurora PostgreSQL](postgresql-ml.md).
+ Invoke AWS Lambda functions from an Aurora PostgreSQL DB cluster. To do this, use the `aws_lambda` PostgreSQL extension provided with Aurora PostgreSQL. For more information, see [Invoking an AWS Lambda function from an Aurora PostgreSQL DB cluster ](PostgreSQL-Lambda.md).
+ Integrate queries from Amazon Redshift and Aurora PostgreSQL. For more information, see [ Getting started with using federated queries to PostgreSQL](https://docs.aws.amazon.com/redshift/latest/dg/getting-started-federated.html) in the *Amazon Redshift Database Developer Guide*.
# Importing data from Amazon S3 into an Aurora PostgreSQL DB cluster
You can import data that's been stored using Amazon Simple Storage Service into a table on an Aurora PostgreSQL DB cluster instance. To do this, you first install the Aurora PostgreSQL `aws_s3` extension. This extension provides the functions that you use to import data from an Amazon S3 bucket. A *bucket* is an Amazon S3 container for objects and files. The data can be in a comma-separate value (CSV) file, a text file, or a compressed (gzip) file. Following, you can learn how to install the extension and how to import data from Amazon S3 into a table.
Your database must be running PostgreSQL version 10.7 or higher to import from Amazon S3 into Aurora PostgreSQL.
If you don't have data stored on Amazon S3, you need to first create a bucket and store the data. For more information, see the following topics in the *Amazon Simple Storage Service User Guide*.
+ [Create a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket)
+ [Add an object to a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#uploading-an-object-bucket)
Cross-account import from Amazon S3 is supported. For more information, see [ Granting cross-account permissions](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) in the *Amazon Simple Storage Service User Guide*.
You can use the customer managed key for encryption while importing data from S3. For more information, see [ KMS keys stored in AWS KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) in the *Amazon Simple Storage Service User Guide*.
**Note**
Importing data from Amazon S3 isn't supported for Aurora Serverless v1. It is supported for Aurora Serverless v2.
**Topics**
+ [Installing the aws\$1s3 extension](USER_PostgreSQL.S3Import.InstallExtension.md)
+ [Overview of importing data from Amazon S3 data](USER_PostgreSQL.S3Import.Overview.md)
+ [Setting up access to an Amazon S3 bucket](USER_PostgreSQL.S3Import.AccessPermission.md)
+ [Importing data from Amazon S3 to your Aurora PostgreSQL DB cluster](USER_PostgreSQL.S3Import.FileFormats.md)
+ [Function reference](USER_PostgreSQL.S3Import.Reference.md)
# Installing the aws\$1s3 extension
Before you can use Amazon S3 with your Aurora PostgreSQL DB cluster, you need to install the `aws_s3` extension. This extension provides functions for importing data from an Amazon S3. It also provides functions for exporting data from an instance of an Aurora PostgreSQL DB cluster to an Amazon S3 bucket. For more information, see [Exporting data from an Aurora PostgreSQL DB cluster to Amazon S3](postgresql-s3-export.md). The `aws_s3` extension depends on some of the helper functions in the `aws_commons` extension, which is installed automatically when needed.
**To install the `aws_s3` extension**
1. Use psql (or pgAdmin) to connect to the writer instance of your Aurora PostgreSQL DB cluster as a user that has `rds_superuser` privileges. If you kept the default name during the setup process, you connect as `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. To install the extension, run the following command.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. To verify that the extension is installed, you can use the psql `\dx` metacommand.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
The functions for importing data from Amazon S3 and exporting data to Amazon S3 are now available to use.
# Overview of importing data from Amazon S3 data
**To import S3 data into Aurora PostgreSQL**
First, gather the details that you need to supply to the function. These include the name of the table on your Aurora PostgreSQL DB cluster's instance, and the bucket name, file path, file type, and AWS Region where the Amazon S3 data is stored. For more information, see [View an object](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) in the *Amazon Simple Storage Service User Guide*.
**Note**
Multi part data import from Amazon S3 isn't currently supported.
1. Get the name of the table into which the `aws_s3.table_import_from_s3` function is to import the data. As an example, the following command creates a table `t1` that can be used in later steps.
```
postgres=> CREATE TABLE t1
(col1 varchar(80),
col2 varchar(80),
col3 varchar(80));
```
1. Get the details about the Amazon S3 bucket and the data to import. To do this, open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/), and choose **Buckets**. Find the bucket containing your data in the list. Choose the bucket, open its Object overview page, and then choose Properties.
Make a note of the bucket name, path, the AWS Region, and file type. You need the Amazon Resource Name (ARN) later, to set up access to Amazon S3 through an IAM role. For more more information, see [Setting up access to an Amazon S3 bucket](USER_PostgreSQL.S3Import.AccessPermission.md). The image following shows an example.
![\[Image of a file object in an Amazon S3 bucket.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aws_s3_import-export_s3_bucket-info.png)
1. You can verify the path to the data on the Amazon S3 bucket by using the AWS CLI command `aws s3 cp`. If the information is correct, this command downloads a copy of the Amazon S3 file.
```
aws s3 cp s3://amzn-s3-demo-bucket/sample_file_path ./
```
1. Set up permissions on your Aurora PostgreSQL DB cluster to allow access to the file on the Amazon S3 bucket. To do so, you use either an AWS Identity and Access Management (IAM) role or security credentials. For more information, see [Setting up access to an Amazon S3 bucket](USER_PostgreSQL.S3Import.AccessPermission.md).
1. Supply the path and other Amazon S3 object details gathered (see step 2) to the `create_s3_uri` function to construct an Amazon S3 URI object. To learn more about this function, see [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri). The following is an example of constructing this object during a psql session.
```
postgres=> SELECT aws_commons.create_s3_uri(
'docs-lab-store-for-rpg',
'versions_and_jdks_listing.csv',
'us-west-1'
) AS s3_uri \gset
```
In the next step, you pass this object (`aws_commons._s3_uri_1`) to the `aws_s3.table_import_from_s3` function to import the data to the table.
1. Invoke the `aws_s3.table_import_from_s3` function to import the data from Amazon S3 into your table. For reference information, see [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3). For examples, see [Importing data from Amazon S3 to your Aurora PostgreSQL DB cluster ](USER_PostgreSQL.S3Import.FileFormats.md).
# Setting up access to an Amazon S3 bucket
To import data from an Amazon S3 file, give the Aurora PostgreSQL DB cluster permission to access the Amazon S3 bucket containing the file. You provide access to an Amazon S3 bucket in one of two ways, as described in the following topics.
**Topics**
+ [Using an IAM role to access an Amazon S3 bucket](#USER_PostgreSQL.S3Import.ARNRole)
+ [Using security credentials to access an Amazon S3 bucket](#USER_PostgreSQL.S3Import.Credentials)
+ [Troubleshooting access to Amazon S3](#USER_PostgreSQL.S3Import.troubleshooting)
## Using an IAM role to access an Amazon S3 bucket
Before you load data from an Amazon S3 file, give your Aurora PostgreSQL DB cluster permission to access the Amazon S3 bucket the file is in. This way, you don't have to manage additional credential information or provide it in the [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) function call.
To do this, create an IAM policy that provides access to the Amazon S3 bucket. Create an IAM role and attach the policy to the role. Then assign the IAM role to your DB cluster.
**Note**
You can't associate an IAM role with an Aurora Serverless v1 DB cluster, so the following steps don't apply.
**To give an Aurora PostgreSQL DB cluster access to Amazon S3 through an IAM role**
1. Create an IAM policy.
This policy provides the bucket and object permissions that allow your Aurora PostgreSQL DB cluster to access Amazon S3.
Include in the policy the following required actions to allow the transfer of files from an Amazon S3 bucket to Aurora PostgreSQL:
+ `s3:GetObject`
+ `s3:ListBucket`
Include in the policy the following resources to identify the Amazon S3 bucket and objects in the bucket. This shows the Amazon Resource Name (ARN) format for accessing Amazon S3.
+ arn:aws:s3:::*amzn-s3-demo-bucket*
+ arn:aws:s3:::*amzn-s3-demo-bucket*/\$1
For more information on creating an IAM policy for Aurora PostgreSQL, see [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md). See also [Tutorial: Create and attach your first customer managed policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) in the *IAM User Guide*.
The following AWS CLI command creates an IAM policy named `rds-s3-import-policy` with these options. It grants access to a bucket named *amzn-s3-demo-bucket*.
**Note**
Make a note of the Amazon Resource Name (ARN) of the policy returned by this command. You need the ARN in a subsequent step when you attach the policy to an IAM role.
**Example**
For Linux, macOS, or Unix:
```
aws iam create-policy \
--policy-name rds-s3-import-policy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
For Windows:
```
aws iam create-policy ^
--policy-name rds-s3-import-policy ^
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3import",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Create an IAM role.
You do this so Aurora PostgreSQL can assume this IAM role to access your Amazon S3 buckets. For more information, see [Creating a role to delegate permissions to an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*.
We recommend using the `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` and `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` global condition context keys in resource-based policies to limit the service's permissions to a specific resource. This is the most effective way to protect against the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
If you use both global condition context keys and the `aws:SourceArn` value contains the account ID, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement.
+ Use `aws:SourceArn` if you want cross-service access for a single resource.
+ Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use.
In the policy, be sure to use the `aws:SourceArn` global condition context key with the full ARN of the resource. The following example shows how to do so using the AWS CLI command to create a role named `rds-s3-import-role`.
**Example**
For Linux, macOS, or Unix:
```
aws iam create-role \
--role-name rds-s3-import-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:cluster:clustername"
}
}
}
]
}'
```
For Windows:
```
aws iam create-role ^
--role-name rds-s3-import-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:cluster:clustername"
}
}
}
]
}'
```
1. Attach the IAM policy that you created to the IAM role that you created.
The following AWS CLI command attaches the policy created in the previous step to the role named `rds-s3-import-role` Replace `your-policy-arn` with the policy ARN that you noted in an earlier step.
**Example**
For Linux, macOS, or Unix:
```
aws iam attach-role-policy \
--policy-arn your-policy-arn \
--role-name rds-s3-import-role
```
For Windows:
```
aws iam attach-role-policy ^
--policy-arn your-policy-arn ^
--role-name rds-s3-import-role
```
1. Add the IAM role to the DB cluster.
You do so by using the AWS Management Console or AWS CLI, as described following.
### Console
**To add an IAM role for a PostgreSQL DB cluster using the console**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choose the PostgreSQL DB cluster name to display its details.
1. On the **Connectivity & security** tab, in the **Manage IAM roles **section, choose the role to add under **Add IAM roles to this cluster **.
1. Under **Feature**, choose **s3Import**.
1. Choose **Add role**.
### AWS CLI
**To add an IAM role for a PostgreSQL DB cluster using the CLI**
+ Use the following command to add the role to the PostgreSQL DB cluster named `my-db-cluster`. Replace *`your-role-arn`* with the role ARN that you noted in a previous step. Use `s3Import` for the value of the `--feature-name` option.
**Example**
For Linux, macOS, or Unix:
```
aws rds add-role-to-db-cluster \
--db-cluster-identifier my-db-cluster \
--feature-name s3Import \
--role-arn your-role-arn \
--region your-region
```
For Windows:
```
aws rds add-role-to-db-cluster ^
--db-cluster-identifier my-db-cluster ^
--feature-name s3Import ^
--role-arn your-role-arn ^
--region your-region
```
### RDS API
To add an IAM role for a PostgreSQL DB cluster using the Amazon RDS API, call the [AddRoleToDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_AddRoleToDBCluster.html) operation.
## Using security credentials to access an Amazon S3 bucket
If you prefer, you can use security credentials to provide access to an Amazon S3 bucket instead of providing access with an IAM role. You do so by specifying the `credentials` parameter in the [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) function call.
The `credentials` parameter is a structure of type `aws_commons._aws_credentials_1`, which contains AWS credentials. Use the [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) function to set the access key and secret key in an `aws_commons._aws_credentials_1` structure, as shown following.
```
postgres=> SELECT aws_commons.create_aws_credentials(
'sample_access_key', 'sample_secret_key', '')
AS creds \gset
```
After creating the `aws_commons._aws_credentials_1 `structure, use the [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) function with the `credentials` parameter to import the data, as shown following.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
:'creds'
);
```
Or you can include the [aws\$1commons.create\$1aws\$1credentials](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_aws_credentials) function call inline within the `aws_s3.table_import_from_s3` function call.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't', '', '(format csv)',
:'s3_uri',
aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
);
```
## Troubleshooting access to Amazon S3
If you encounter connection problems when attempting to import data from Amazon S3, see the following for recommendations:
+ [Troubleshooting Amazon Aurora identity and access](security_iam_troubleshoot.md)
+ [Troubleshooting Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) in the *Amazon Simple Storage Service User Guide*
+ [Troubleshooting Amazon S3 and IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) in the *IAM User Guide*
# Importing data from Amazon S3 to your Aurora PostgreSQL DB cluster
You import data from your Amazon S3 bucket by using the `table_import_from_s3` function of the aws\$1s3 extension. For reference information, see [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
**Note**
The following examples use the IAM role method to allow access to the Amazon S3 bucket. Thus, the `aws_s3.table_import_from_s3` function calls don't include credential parameters.
The following shows a typical example.
```
postgres=> SELECT aws_s3.table_import_from_s3(
't1',
'',
'(format csv)',
:'s3_uri'
);
```
The parameters are the following:
+ `t1` – The name for the table in the PostgreSQL DB cluster to copy the data into.
+ `''` – An optional list of columns in the database table. You can use this parameter to indicate which columns of the S3 data go in which table columns. If no columns are specified, all the columns are copied to the table. For an example of using a column list, see [Importing an Amazon S3 file that uses a custom delimiter](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
+ `(format csv)` – PostgreSQL COPY arguments. The copy process uses the arguments and format of the [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) command to import the data. Choices for format include comma-separated value (CSV) as shown in this example, text, and binary. The default is text.
+ `s3_uri` – A structure that contains the information identifying the Amazon S3 file. For an example of using the [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) function to create an `s3_uri` structure, see [Overview of importing data from Amazon S3 data](USER_PostgreSQL.S3Import.Overview.md).
For more information about this function, see [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3).
The `aws_s3.table_import_from_s3` function returns text. To specify other kinds of files for import from an Amazon S3 bucket, see one of the following examples.
**Note**
Importing 0 bytes file will cause an error.
**Topics**
+ [Importing an Amazon S3 file that uses a custom delimiter](#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter)
+ [Importing an Amazon S3 compressed (gzip) file](#USER_PostgreSQL.S3Import.FileFormats.gzip)
+ [Importing an encoded Amazon S3 file](#USER_PostgreSQL.S3Import.FileFormats.Encoded)
## Importing an Amazon S3 file that uses a custom delimiter
The following example shows how to import a file that uses a custom delimiter. It also shows how to control where to put the data in the database table using the `column_list` parameter of the [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) function.
For this example, assume that the following information is organized into pipe-delimited columns in the Amazon S3 file.
```
1|foo1|bar1|elephant1
2|foo2|bar2|elephant2
3|foo3|bar3|elephant3
4|foo4|bar4|elephant4
...
```
**To import a file that uses a custom delimiter**
1. Create a table in the database for the imported data.
```
postgres=> CREATE TABLE test (a text, b text, c text, d text, e text);
```
1. Use the following form of the [aws\$1s3.table\$1import\$1from\$1s3](USER_PostgreSQL.S3Import.Reference.md#aws_s3.table_import_from_s3) function to import data from the Amazon S3 file.
You can include the [aws\$1commons.create\$1s3\$1uri](USER_PostgreSQL.S3Import.Reference.md#USER_PostgreSQL.S3Import.create_s3_uri) function call inline within the `aws_s3.table_import_from_s3` function call to specify the file.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test',
'a,b,d,e',
'DELIMITER ''|''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'pipeDelimitedSampleFile', 'us-east-2')
);
```
The data is now in the table in the following columns.
```
postgres=> SELECT * FROM test;
a | b | c | d | e
---+------+---+---+------+-----------
1 | foo1 | | bar1 | elephant1
2 | foo2 | | bar2 | elephant2
3 | foo3 | | bar3 | elephant3
4 | foo4 | | bar4 | elephant4
```
## Importing an Amazon S3 compressed (gzip) file
The following example shows how to import a file from Amazon S3 that is compressed with gzip. The file that you import needs to have the following Amazon S3 metadata:
+ Key: `Content-Encoding`
+ Value: `gzip`
If you upload the file using the AWS Management Console, the metadata is typically applied by the system. For information about uploading files to Amazon S3 using the AWS Management Console, the AWS CLI, or the API, see [Uploading objects](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) in the *Amazon Simple Storage Service User Guide*.
For more information about Amazon S3 metadata and details about system-provided metadata, see [Editing object metadata in the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-object-metadata.html) in the *Amazon Simple Storage Service User Guide*.
Import the gzip file into your Aurora PostgreSQL DB cluster as shown following.
```
postgres=> CREATE TABLE test_gzip(id int, a text, b text, c text, d text);
postgres=> SELECT aws_s3.table_import_from_s3(
'test_gzip', '', '(format csv)',
'amzn-s3-demo-bucket', 'test-data.gz', 'us-east-2'
);
```
## Importing an encoded Amazon S3 file
The following example shows how to import a file from Amazon S3 that has Windows-1252 encoding.
```
postgres=> SELECT aws_s3.table_import_from_s3(
'test_table', '', 'encoding ''WIN1252''',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'SampleFile', 'us-east-2')
);
```
# Function reference
**Topics**
+ [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3)
+ [aws\$1commons.create\$1s3\$1uri](#USER_PostgreSQL.S3Import.create_s3_uri)
+ [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials)
## aws\$1s3.table\$1import\$1from\$1s3
Imports Amazon S3 data into an Aurora PostgreSQL table. The `aws_s3` extension provides the `aws_s3.table_import_from_s3` function. The return value is text.
### Syntax
The required parameters are `table_name`, `column_list` and `options`. These identify the database table and specify how the data is copied into the table.
You can also use the following parameters:
+ The `s3_info` parameter specifies the Amazon S3 file to import. When you use this parameter, access to Amazon S3 is provided by an IAM role for the PostgreSQL DB cluster.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1
)
```
+ The `credentials` parameter specifies the credentials to access Amazon S3. When you use this parameter, you don't use an IAM role.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
s3_info aws_commons._s3_uri_1,
credentials aws_commons._aws_credentials_1
)
```
### Parameters
*table\$1name*
A required text string containing the name of the PostgreSQL database table to import the data into.
*column\$1list*
A required text string containing an optional list of the PostgreSQL database table columns in which to copy the data. If the string is empty, all columns of the table are used. For an example, see [Importing an Amazon S3 file that uses a custom delimiter](USER_PostgreSQL.S3Import.FileFormats.md#USER_PostgreSQL.S3Import.FileFormats.CustomDelimiter).
*options*
A required text string containing arguments for the PostgreSQL `COPY` command. These arguments specify how the data is to be copied into the PostgreSQL table. For more details, see the [PostgreSQL COPY documentation](https://www.postgresql.org/docs/current/sql-copy.html).
*s3\$1info*
An `aws_commons._s3_uri_1` composite type containing the following information about the S3 object:
+ `bucket` – The name of the Amazon S3 bucket containing the file.
+ `file_path` – The Amazon S3 file name including the path of the file.
+ `region` – The AWS Region that the file is in. For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
*credentials*
An `aws_commons._aws_credentials_1` composite type containing the following credentials to use for the import operation:
+ Access key
+ Secret key
+ Session token
For information about creating an `aws_commons._aws_credentials_1` composite structure, see [aws\$1commons.create\$1aws\$1credentials](#USER_PostgreSQL.S3Import.create_aws_credentials).
### Alternate syntax
To help with testing, you can use an expanded set of parameters instead of the `s3_info` and `credentials` parameters. Following are additional syntax variations for the `aws_s3.table_import_from_s3` function:
+ Instead of using the `s3_info` parameter to identify an Amazon S3 file, use the combination of the `bucket`, `file_path`, and `region` parameters. With this form of the function, access to Amazon S3 is provided by an IAM role on the PostgreSQL DB instance.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text
)
```
+ Instead of using the `credentials` parameter to specify Amazon S3 access, use the combination of the `access_key`, `session_key`, and `session_token` parameters.
```
aws_s3.table_import_from_s3 (
table_name text,
column_list text,
options text,
bucket text,
file_path text,
region text,
access_key text,
secret_key text,
session_token text
)
```
### Alternate parameters
*bucket*
A text string containing the name of the Amazon S3 bucket that contains the file.
*file\$1path*
A text string containing the Amazon S3 file name including the path of the file.
*region*
A text string identifying the AWS Region location of the file. For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
*access\$1key*
A text string containing the access key to use for the import operation. The default is NULL.
*secret\$1key*
A text string containing the secret key to use for the import operation. The default is NULL.
*session\$1token*
(Optional) A text string containing the session key to use for the import operation. The default is NULL.
## aws\$1commons.create\$1s3\$1uri
Creates an `aws_commons._s3_uri_1` structure to hold Amazon S3 file information. Use the results of the `aws_commons.create_s3_uri` function in the `s3_info` parameter of the [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3) function.
### Syntax
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```
### Parameters
*bucket*
A required text string containing the Amazon S3 bucket name for the file.
*file\$1path*
A required text string containing the Amazon S3 file name including the path of the file.
*region*
A required text string containing the AWS Region that the file is in. For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1commons.create\$1aws\$1credentials
Sets an access key and secret key in an `aws_commons._aws_credentials_1` structure. Use the results of the `aws_commons.create_aws_credentials` function in the `credentials` parameter of the [aws\$1s3.table\$1import\$1from\$1s3](#aws_s3.table_import_from_s3) function.
### Syntax
```
aws_commons.create_aws_credentials(
access_key text,
secret_key text,
session_token text
)
```
### Parameters
*access\$1key*
A required text string containing the access key to use for importing an Amazon S3 file. The default is NULL.
*secret\$1key*
A required text string containing the secret key to use for importing an Amazon S3 file. The default is NULL.
*session\$1token*
An optional text string containing the session token to use for importing an Amazon S3 file. The default is NULL. If you provide an optional `session_token`, you can use temporary credentials.
# Exporting data from an Aurora PostgreSQL DB cluster to Amazon S3
You can query data from an Aurora PostgreSQL DB cluster and export it directly into files stored in an Amazon S3 bucket. To do this, you first install the Aurora PostgreSQL `aws_s3` extension. This extension provides you with the functions that you use to export the results of queries to Amazon S3. Following, you can find out how to install the extension and how to export data to Amazon S3.
You can export from a provisioned or an Aurora Serverless v2 DB instance. These steps aren't supported for Aurora Serverless v1.
**Note**
Cross-account export to Amazon S3 isn't supported.
All currently available versions of Aurora PostgreSQL support exporting data to Amazon Simple Storage Service. For detailed version information, see [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) in the *Release Notes for Aurora PostgreSQL*.
If you don't have a bucket set up for your export, see the following topics the *Amazon Simple Storage Service User Guide*.
+ [Setting up Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html)
+ [Creating a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)
By default, the data exported from Aurora PostgreSQL to Amazon S3 uses server-side encryption with AWS managed key. You can alternatively use customer managed key that you have already created. If you are using bucket encryption, the Amazon S3 bucket must be encrypted with AWS Key Management Service (AWS KMS) key (SSE-KMS). Currently, buckets encrypted with Amazon S3 managed keys (SSE-S3) are not supported.
**Note**
You can save DB and DB cluster snapshot data to Amazon S3 using the AWS Management Console, AWS CLI, or Amazon RDS API. For more information, see [Exporting DB cluster snapshot data to Amazon S3](aurora-export-snapshot.md).
**Topics**
+ [Installing the aws\$1s3 extension](#USER_PostgreSQL.S3Export.InstallExtension)
+ [Overview of exporting data to Amazon S3](#postgresql-s3-export-overview)
+ [Specifying the Amazon S3 file path to export to](#postgresql-s3-export-file)
+ [Setting up access to an Amazon S3 bucket](postgresql-s3-export-access-bucket.md)
+ [Exporting query data using the aws\$1s3.query\$1export\$1to\$1s3 function](postgresql-s3-export-examples.md)
+ [Function reference](postgresql-s3-export-functions.md)
+ [Troubleshooting access to Amazon S3](postgresql-s3-export-troubleshoot.md)
## Installing the aws\$1s3 extension
Before you can use Amazon Simple Storage Service with your Aurora PostgreSQL DB cluster, you need to install the `aws_s3` extension. This extension provides functions for exporting data from the writer instance of an Aurora PostgreSQL DB cluster to an Amazon S3 bucket. It also provides functions for importing data from an Amazon S3. For more information, see [Importing data from Amazon S3 into an Aurora PostgreSQL DB cluster](USER_PostgreSQL.S3Import.md). The `aws_s3` extension depends on some of the helper functions in the `aws_commons` extension, which is installed automatically when needed.
**To install the `aws_s3` extension**
1. Use psql (or pgAdmin) to connect to the writer instance of your Aurora PostgreSQL DB cluster as a user that has `rds_superuser` privileges. If you kept the default name during the setup process, you connect as `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. To install the extension, run the following command.
```
postgres=> CREATE EXTENSION aws_s3 CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
1. To verify that the extension is installed, you can use the psql `\dx` metacommand.
```
postgres=> \dx
List of installed extensions
Name | Version | Schema | Description
-------------+---------+------------+---------------------------------------------
aws_commons | 1.2 | public | Common data types across AWS services
aws_s3 | 1.1 | public | AWS S3 extension for importing data from S3
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
The functions for importing data from Amazon S3 and exporting data to Amazon S3 are now available to use.
### Verify that your Aurora PostgreSQL version supports exports to Amazon S3
You can verify that your Aurora PostgreSQL version supports export to Amazon S3 by using the `describe-db-engine-versions` command. The following example checks to see if version 10.14 can export to Amazon S3.
```
aws rds describe-db-engine-versions --region us-east-1 \
--engine aurora-postgresql --engine-version 10.14 | grep s3Export
```
If the output includes the string `"s3Export"`, then the engine supports Amazon S3 exports. Otherwise, the engine doesn't support them.
## Overview of exporting data to Amazon S3
To export data stored in an Aurora PostgreSQL database to an Amazon S3 bucket, use the following procedure.
**To export Aurora PostgreSQL data to S3**
1. Identify an Amazon S3 file path to use for exporting data. For details about this process, see [Specifying the Amazon S3 file path to export to](#postgresql-s3-export-file).
1. Provide permission to access the Amazon S3 bucket.
To export data to an Amazon S3 file, give the Aurora PostgreSQL DB cluster permission to access the Amazon S3 bucket that the export will use for storage. Doing this includes the following steps:
1. Create an IAM policy that provides access to an Amazon S3 bucket that you want to export to.
1. Create an IAM role.
1. Attach the policy you created to the role you created.
1. Add this IAM role to your DB cluster .
For details about this process, see [Setting up access to an Amazon S3 bucket](postgresql-s3-export-access-bucket.md).
1. Identify a database query to get the data. Export the query data by calling the `aws_s3.query_export_to_s3` function.
After you complete the preceding preparation tasks, use the [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) function to export query results to Amazon S3. For details about this process, see [Exporting query data using the aws\$1s3.query\$1export\$1to\$1s3 function](postgresql-s3-export-examples.md).
## Specifying the Amazon S3 file path to export to
Specify the following information to identify the location in Amazon S3 where you want to export data to:
+ Bucket name – A *bucket* is a container for Amazon S3 objects or files.
For more information on storing data with Amazon S3, see [ Creating a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) and [Working with objects](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) in the *Amazon Simple Storage Service User Guide*.
+ File path – The file path identifies where the export is stored in the Amazon S3 bucket. The file path consists of the following:
+ An optional path prefix that identifies a virtual folder path.
+ A file prefix that identifies one or more files to be stored. Larger exports are stored in multiple files, each with a maximum size of approximately 6 GB. The additional file names have the same file prefix but with `_partXX` appended. The `XX` represents 2, then 3, and so on.
For example, a file path with an `exports` folder and a `query-1-export` file prefix is `/exports/query-1-export`.
+ AWS Region (optional) – The AWS Region where the Amazon S3 bucket is located. If you don't specify an AWS Region value, then Aurora saves your files into Amazon S3 in the same AWS Region as the exporting DB cluster.
**Note**
Currently, the AWS Region must be the same as the region of the exporting DB cluster.
For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
To hold the Amazon S3 file information about where the export is to be stored, you can use the [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) function to create an `aws_commons._s3_uri_1` composite structure as follows.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
You later provide this `s3_uri_1` value as a parameter in the call to the [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) function. For examples, see [Exporting query data using the aws\$1s3.query\$1export\$1to\$1s3 function](postgresql-s3-export-examples.md).
# Setting up access to an Amazon S3 bucket
To export data to Amazon S3, give your PostgreSQL DB cluster permission to access the Amazon S3 bucket that the files are to go in.
To do this, use the following procedure.
**To give a PostgreSQL DB cluster access to Amazon S3 through an IAM role**
1. Create an IAM policy.
This policy provides the bucket and object permissions that allow your PostgreSQL DB cluster to access Amazon S3.
As part of creating this policy, take the following steps:
1. Include in the policy the following required actions to allow the transfer of files from your PostgreSQL DB cluster to an Amazon S3 bucket:
+ `s3:PutObject`
+ `s3:AbortMultipartUpload`
1. Include the Amazon Resource Name (ARN) that identifies the Amazon S3 bucket and objects in the bucket. The ARN format for accessing Amazon S3 is: `arn:aws:s3:::amzn-s3-demo-bucket/*`
For more information on creating an IAM policy for Aurora PostgreSQL, see [Creating and using an IAM policy for IAM database access](UsingWithRDS.IAMDBAuth.IAMPolicy.md). See also [Tutorial: Create and attach your first customer managed policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) in the *IAM User Guide*.
The following AWS CLI command creates an IAM policy named `rds-s3-export-policy` with these options. It grants access to a bucket named *amzn-s3-demo-bucket*.
**Warning**
We recommend that you set up your database within a private VPC that has endpoint policies configured for accessing specific buckets. For more information, see [ Using endpoint policies for Amazon S3](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html#vpc-endpoints-policies-s3) in the Amazon VPC User Guide.
We strongly recommend that you do not create a policy with all-resource access. This access can pose a threat for data security. If you create a policy that gives `S3:PutObject` access to all resources using `"Resource":"*"`, then a user with export privileges can export data to all buckets in your account. In addition, the user can export data to *any publicly writable bucket within your AWS Region*.
After you create the policy, note the Amazon Resource Name (ARN) of the policy. You need the ARN for a subsequent step when you attach the policy to an IAM role.
```
aws iam create-policy --policy-name rds-s3-export-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "s3export",
"Action": [
"s3:PutObject*",
"s3:ListBucket",
"s3:GetObject*",
"s3:DeleteObject*",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
]
}'
```
1. Create an IAM role.
You do this so Aurora PostgreSQL can assume this IAM role on your behalf to access your Amazon S3 buckets. For more information, see [Creating a role to delegate permissions to an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*.
We recommend using the `[aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)` and `[aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)` global condition context keys in resource-based policies to limit the service's permissions to a specific resource. This is the most effective way to protect against the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html).
If you use both global condition context keys and the `aws:SourceArn` value contains the account ID, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement.
+ Use `aws:SourceArn` if you want cross-service access for a single resource.
+ Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use.
In the policy, be sure to use the `aws:SourceArn` global condition context key with the full ARN of the resource. The following example shows how to do so using the AWS CLI command to create a role named `rds-s3-export-role`.
**Example**
For Linux, macOS, or Unix:
```
aws iam create-role \
--role-name rds-s3-export-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:cluster:dbname"
}
}
}
]
}'
```
For Windows:
```
aws iam create-role ^
--role-name rds-s3-export-role ^
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333",
"aws:SourceArn": "arn:aws:rds:us-east-1:111122223333:cluster:dbname"
}
}
}
]
}'
```
1. Attach the IAM policy that you created to the IAM role that you created.
The following AWS CLI command attaches the policy created earlier to the role named `rds-s3-export-role.` Replace `your-policy-arn` with the policy ARN that you noted in an earlier step.
```
aws iam attach-role-policy --policy-arn your-policy-arn --role-name rds-s3-export-role
```
1. Add the IAM role to the DB cluster. You do so by using the AWS Management Console or AWS CLI, as described following.
## Console
**To add an IAM role for a PostgreSQL DB cluster using the console**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choose the PostgreSQL DB cluster name to display its details.
1. On the **Connectivity & security** tab, in the **Manage IAM roles **section, choose the role to add under **Add IAM roles to this instance**.
1. Under **Feature**, choose **s3Export**.
1. Choose **Add role**.
## AWS CLI
**To add an IAM role for a PostgreSQL DB cluster using the CLI**
+ Use the following command to add the role to the PostgreSQL DB cluster named `my-db-cluster`. Replace *`your-role-arn`* with the role ARN that you noted in a previous step. Use `s3Export` for the value of the `--feature-name` option.
**Example**
For Linux, macOS, or Unix:
```
aws rds add-role-to-db-cluster \
--db-cluster-identifier my-db-cluster \
--feature-name s3Export \
--role-arn your-role-arn \
--region your-region
```
For Windows:
```
aws rds add-role-to-db-cluster ^
--db-cluster-identifier my-db-cluster ^
--feature-name s3Export ^
--role-arn your-role-arn ^
--region your-region
```
# Exporting query data using the aws\$1s3.query\$1export\$1to\$1s3 function
Export your PostgreSQL data to Amazon S3 by calling the [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) function.
**Topics**
+ [Prerequisites](#postgresql-s3-export-examples-prerequisites)
+ [Calling aws\$1s3.query\$1export\$1to\$1s3](#postgresql-s3-export-examples-basic)
+ [Exporting to a CSV file that uses a custom delimiter](#postgresql-s3-export-examples-custom-delimiter)
+ [Exporting to a binary file with encoding](#postgresql-s3-export-examples-encoded)
## Prerequisites
Before you use the `aws_s3.query_export_to_s3` function, be sure to complete the following prerequisites:
+ Install the required PostgreSQL extensions as described in [Overview of exporting data to Amazon S3](postgresql-s3-export.md#postgresql-s3-export-overview).
+ Determine where to export your data to Amazon S3 as described in [Specifying the Amazon S3 file path to export to](postgresql-s3-export.md#postgresql-s3-export-file).
+ Make sure that the DB cluster has export access to Amazon S3 as described in [Setting up access to an Amazon S3 bucket](postgresql-s3-export-access-bucket.md).
The examples following use a database table called `sample_table`. These examples export the data into a bucket called *amzn-s3-demo-bucket*. The example table and data are created with the following SQL statements in psql.
```
psql=> CREATE TABLE sample_table (bid bigint PRIMARY KEY, name varchar(80));
psql=> INSERT INTO sample_table (bid,name) VALUES (1, 'Monday'), (2,'Tuesday'), (3, 'Wednesday');
```
## Calling aws\$1s3.query\$1export\$1to\$1s3
The following shows the basic ways of calling the [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) function.
These examples use the variable `s3_uri_1` to identify a structure that contains the information identifying the Amazon S3 file. Use the [aws\$1commons.create\$1s3\$1uri](postgresql-s3-export-functions.md#aws_commons.create_s3_uri) function to create the structure.
```
psql=> SELECT aws_commons.create_s3_uri(
'amzn-s3-demo-bucket',
'sample-filepath',
'us-west-2'
) AS s3_uri_1 \gset
```
Although the parameters vary for the following two `aws_s3.query_export_to_s3` function calls, the results are the same for these examples. All rows of the `sample_table` table are exported into a bucket called *amzn-s3-demo-bucket*.
```
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1');
psql=> SELECT * FROM aws_s3.query_export_to_s3('SELECT * FROM sample_table', :'s3_uri_1', options :='format text');
```
The parameters are described as follows:
+ `'SELECT * FROM sample_table'` – The first parameter is a required text string containing an SQL query. The PostgreSQL engine runs this query. The results of the query are copied to the S3 bucket identified in other parameters.
+ `:'s3_uri_1'` – This parameter is a structure that identifies the Amazon S3 file. This example uses a variable to identify the previously created structure. You can instead create the structure by including the `aws_commons.create_s3_uri` function call inline within the `aws_s3.query_export_to_s3` function call as follows.
```
SELECT * from aws_s3.query_export_to_s3('select * from sample_table',
aws_commons.create_s3_uri('amzn-s3-demo-bucket', 'sample-filepath', 'us-west-2')
);
```
+ `options :='format text'` – The `options` parameter is an optional text string containing PostgreSQL `COPY` arguments. The copy process uses the arguments and format of the [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) command.
If the file specified doesn't exist in the Amazon S3 bucket, it's created. If the file already exists, it's overwritten. The syntax for accessing the exported data in Amazon S3 is the following.
```
s3-region://bucket-name[/path-prefix]/file-prefix
```
Larger exports are stored in multiple files, each with a maximum size of approximately 6 GB. The additional file names have the same file prefix but with `_partXX` appended. The `XX` represents 2, then 3, and so on. For example, suppose that you specify the path where you store data files as the following.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
```
If the export has to create three data files, the Amazon S3 bucket contains the following data files.
```
s3-us-west-2://amzn-s3-demo-bucket/my-prefix
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part2
s3-us-west-2://amzn-s3-demo-bucket/my-prefix_part3
```
For the full reference for this function and additional ways to call it, see [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3). For more about accessing files in Amazon S3, see [View an object](https://docs.aws.amazon.com/AmazonS3/latest/userguide/OpeningAnObject.html) in the *Amazon Simple Storage Service User Guide*.
## Exporting to a CSV file that uses a custom delimiter
The following example shows how to call the [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) function to export data to a file that uses a custom delimiter. The example uses arguments of the [PostgreSQL COPY](https://www.postgresql.org/docs/current/sql-copy.html) command to specify the comma-separated value (CSV) format and a colon (:) delimiter.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format csv, delimiter $$:$$');
```
## Exporting to a binary file with encoding
The following example shows how to call the [aws\$1s3.query\$1export\$1to\$1s3](postgresql-s3-export-functions.md#aws_s3.export_query_to_s3) function to export data to a binary file that has Windows-1253 encoding.
```
SELECT * from aws_s3.query_export_to_s3('select * from basic_test', :'s3_uri_1', options :='format binary, encoding WIN1253');
```
# Function reference
**Topics**
+ [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3)
+ [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri)
## aws\$1s3.query\$1export\$1to\$1s3
Exports a PostgreSQL query result to an Amazon S3 bucket. The `aws_s3` extension provides the `aws_s3.query_export_to_s3` function.
The two required parameters are `query` and `s3_info`. These define the query to be exported and identify the Amazon S3 bucket to export to. An optional parameter called `options` provides for defining various export parameters. For examples of using the `aws_s3.query_export_to_s3` function, see [Exporting query data using the aws\$1s3.query\$1export\$1to\$1s3 function](postgresql-s3-export-examples.md).
**Syntax**
```
aws_s3.query_export_to_s3(
query text,
s3_info aws_commons._s3_uri_1,
options text,
kms_key text
)
```Input parameters
*query*
A required text string containing an SQL query that the PostgreSQL engine runs. The results of this query are copied to an S3 bucket identified in the `s3_info` parameter.
*s3\$1info*
An `aws_commons._s3_uri_1` composite type containing the following information about the S3 object:
+ `bucket` – The name of the Amazon S3 bucket to contain the file.
+ `file_path` – The Amazon S3 file name and path.
+ `region` – The AWS Region that the bucket is in. For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
Currently, this value must be the same AWS Region as that of the exporting DB cluster . The default is the AWS Region of the exporting DB cluster .
To create an `aws_commons._s3_uri_1` composite structure, see the [aws\$1commons.create\$1s3\$1uri](#aws_commons.create_s3_uri) function.
*options*
An optional text string containing arguments for the PostgreSQL `COPY` command. These arguments specify how the data is to be copied when exported. For more details, see the [PostgreSQL COPY documentation](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
An optional text string containing the customer managed KMS key of the S3 bucket to export the data to.
### Alternate input parameters
To help with testing, you can use an expanded set of parameters instead of the `s3_info` parameter. Following are additional syntax variations for the `aws_s3.query_export_to_s3` function.
Instead of using the `s3_info` parameter to identify an Amazon S3 file, use the combination of the `bucket`, `file_path`, and `region` parameters.
```
aws_s3.query_export_to_s3(
query text,
bucket text,
file_path text,
region text,
options text,
kms_key text
)
```
*query*
A required text string containing an SQL query that the PostgreSQL engine runs. The results of this query are copied to an S3 bucket identified in the `s3_info` parameter.
*bucket*
A required text string containing the name of the Amazon S3 bucket that contains the file.
*file\$1path*
A required text string containing the Amazon S3 file name including the path of the file.
*region*
An optional text string containing the AWS Region that the bucket is in. For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
Currently, this value must be the same AWS Region as that of the exporting DB cluster . The default is the AWS Region of the exporting DB cluster .
*options*
An optional text string containing arguments for the PostgreSQL `COPY` command. These arguments specify how the data is to be copied when exported. For more details, see the [PostgreSQL COPY documentation](https://www.postgresql.org/docs/current/sql-copy.html).
*kms\$1key text*
An optional text string containing the customer managed KMS key of the S3 bucket to export the data to.
### Output parameters
```
aws_s3.query_export_to_s3(
OUT rows_uploaded bigint,
OUT files_uploaded bigint,
OUT bytes_uploaded bigint
)
```
*rows\$1uploaded*
The number of table rows that were successfully uploaded to Amazon S3 for the given query.
*files\$1uploaded*
The number of files uploaded to Amazon S3. Files are created in sizes of approximately 6 GB. Each additional file created has `_partXX` appended to the name. The `XX` represents 2, then 3, and so on as needed.
*bytes\$1uploaded*
The total number of bytes uploaded to Amazon S3.
### Examples
```
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2');
psql=> SELECT * from aws_s3.query_export_to_s3('select * from sample_table', 'amzn-s3-demo-bucket', 'sample-filepath','us-west-2','format text');
```
## aws\$1commons.create\$1s3\$1uri
Creates an `aws_commons._s3_uri_1` structure to hold Amazon S3 file information. You use the results of the `aws_commons.create_s3_uri` function in the `s3_info` parameter of the [aws\$1s3.query\$1export\$1to\$1s3](#aws_s3.export_query_to_s3) function. For an example of using the `aws_commons.create_s3_uri` function, see [Specifying the Amazon S3 file path to export to](postgresql-s3-export.md#postgresql-s3-export-file).
**Syntax**
```
aws_commons.create_s3_uri(
bucket text,
file_path text,
region text
)
```Input parameters
*bucket*
A required text string containing the Amazon S3 bucket name for the file.
*file\$1path*
A required text string containing the Amazon S3 file name including the path of the file.
*region*
A required text string containing the AWS Region that the file is in. For a listing of AWS Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
# Troubleshooting access to Amazon S3
If you encounter connection problems when attempting to export data to Amazon S3, first confirm that the outbound access rules for the VPC security group associated with your DB instance permit network connectivity. Specifically, the security group must have a rule that allows the DB instance to send TCP traffic to port 443 and to any IPv4 addresses (0.0.0.0/0). For more information, see [Provide access to the DB cluster in the VPC by creating a security group](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup).
See also the following for recommendations:
+ [Troubleshooting Amazon Aurora identity and access](security_iam_troubleshoot.md)
+ [Troubleshooting Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshooting.html) in the *Amazon Simple Storage Service User Guide*
+ [Troubleshooting Amazon S3 and IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_iam-s3.html) in the *IAM User Guide*
# Invoking an AWS Lambda function from an Aurora PostgreSQL DB cluster
AWS Lambda is an event-driven compute service that lets you run code without provisioning or managing servers. It's available for use with many AWS services, including Aurora PostgreSQL. For example, you can use Lambda functions to process event notifications from a database, or to load data from files whenever a new file is uploaded to Amazon S3. To learn more about Lambda, see [What is AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) in the *AWS Lambda Developer Guide.*
**Note**
Invoking AWS Lambda functions is supported in Aurora PostgreSQL 11.9 and higher (including Aurora Serverless v2).
Setting up Aurora PostgreSQL to work with Lambda functions is a multi-step process involving AWS Lambda, IAM, your VPC, and your Aurora PostgreSQL DB cluster. Following, you can find summaries of the necessary steps.
For more information about Lambda functions, see [Getting started with Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) and [AWS Lambda foundations](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) in the *AWS Lambda Developer Guide*.
**Topics**
+ [Step 1: Configure your Aurora PostgreSQL DB cluster for outbound connections to AWS Lambda](#PostgreSQL-Lambda-network)
+ [Step 2: Configure IAM for your Aurora PostgreSQL DB cluster and AWS Lambda](#PostgreSQL-Lambda-access)
+ [Step 3: Install the `aws_lambda` extension for an Aurora PostgreSQL DB cluster](#PostgreSQL-Lambda-install-extension)
+ [Step 4: Use Lambda helper functions with your Aurora PostgreSQL DB cluster (Optional)](#PostgreSQL-Lambda-specify-function)
+ [Step 5: Invoke a Lambda function from your Aurora PostgreSQL DB cluster](#PostgreSQL-Lambda-invoke)
+ [Step 6: Grant other users permission to invoke Lambda functions](#PostgreSQL-Lambda-grant-users-permissions)
+ [Examples: Invoking Lambda functions from your Aurora PostgreSQL DB cluster](PostgreSQL-Lambda-examples.md)
+ [Lambda function error messages](PostgreSQL-Lambda-errors.md)
+ [AWS Lambda function and parameter reference](PostgreSQL-Lambda-functions.md)
## Step 1: Configure your Aurora PostgreSQL DB cluster for outbound connections to AWS Lambda
Lambda functions always run inside an Amazon VPC that's owned by the AWS Lambda service. Lambda applies network access and security rules to this VPC and it maintains and monitors the VPC automatically. Your Aurora PostgreSQL DB cluster sends network traffic to the Lambda service's VPC. How you configure this depends on whether your Aurora DB cluster's primary DB instance is public or private.
+ **Public Aurora PostgreSQL DB cluster** – A DB cluster's primary DB instance is public if it's located in a public subnet on your VPC, and if the instance's "PubliclyAccessible" property is `true`. To find the value of this property, you can use the [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI command. Or, you can use the AWS Management Console to open the **Connectivity & security** tab and check that **Publicly accessible** is **Yes**. To verify that the instance is in the public subnet of your VPC, you can use the AWS Management Console or the AWS CLI.
To set up access to Lambda, you use the AWS Management Console or the AWS CLI to create an outbound rule on your VPC's security group. The outbound rule specifies that TCP can use port 443 to send packets to any IPv4 addresses (0.0.0.0/0).
+ **Private Aurora PostgreSQL DB cluster** – In this case, the instance's "PubliclyAccessible" property is `false` or it's in a private subnet. To allow the instance to work with Lambda, you can use a Network Address Translation) NAT gateway. For more information, see [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). Or, you can configure your VPC with a VPC endpoint for Lambda. For more information, see [VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) in the *Amazon VPC User Guide*. The endpoint responds to calls made by your Aurora PostgreSQL DB cluster to your Lambda functions.
Your VPC can now interact with the AWS Lambda VPC at the network level. Next, you configure the permissions using IAM.
## Step 2: Configure IAM for your Aurora PostgreSQL DB cluster and AWS Lambda
Invoking Lambda functions from your Aurora PostgreSQL DB cluster requires certain privileges. To configure the necessary privileges, we recommend that you create an IAM policy that allows invoking Lambda functions, assign that policy to a role, and then apply the role to your DB cluster. This approach gives the DB cluster privileges to invoke the specified Lambda function on your behalf. The following steps show you how to do this using the AWS CLI.
**To configure IAM permissions for using your cluster with Lambda**
1. Use the [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) AWS CLI command to create an IAM policy that allows your Aurora PostgreSQL DB cluster to invoke the specified Lambda function. (The statement ID (Sid) is an optional description for your policy statement and has no effect on usage.) This policy gives your Aurora DB cluster the minimum permissions needed to invoke the specified Lambda function.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
Alternatively, you can use the predefined `AWSLambdaRole` policy that allows you to invoke any of your Lambda functions. For more information, see [Identity-based IAM policies for Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed)
1. Use the [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) AWS CLI command to create an IAM role that the policy can assume at runtime.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Apply the policy to the role by using the [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) AWS CLI command.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. Apply the role to your Aurora PostgreSQL DB cluster by using the [add-role-to-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/add-role-to-db-cluster.html) AWS CLI command. This last step allows your DB cluster's database users to invoke Lambda functions.
```
aws rds add-role-to-db-cluster \
--db-cluster-identifier my-cluster-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
With the VPC and the IAM configurations complete, you can now install the `aws_lambda` extension. (Note that you can install the extension at any time, but until you set up the correct VPC support and IAM privileges, the `aws_lambda` extension adds nothing to your Aurora PostgreSQL DB cluster's capabilities.)
## Step 3: Install the `aws_lambda` extension for an Aurora PostgreSQL DB cluster
To use AWS Lambda with your Aurora PostgreSQL DB cluster, add the `aws_lambda` PostgreSQL extension to your Aurora PostgreSQL DB cluster. This extension provides your Aurora PostgreSQL DB cluster with the ability to call Lambda functions from PostgreSQL.
**To install the `aws_lambda` extension in your Aurora PostgreSQL DB cluster**
Use the PostgreSQL `psql` command-line or the pgAdmin tool to connect to your Aurora PostgreSQL DB cluster .
1. Connect to your Aurora PostgreSQL DB cluster instance as a user with `rds_superuser` privileges. The default `postgres` user is shown in the example.
```
psql -h cluster-instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Install the `aws_lambda` extension. The `aws_commons` extension is also required. It provides helper functions to `aws_lambda` and many other Aurora extensions for PostgreSQL. If it's not already on your Aurora PostgreSQLDB cluster , it's installed with `aws_lambda` as shown following.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
The `aws_lambda` extension is installed in your Aurora PostgreSQL DB cluster's primary DB instance. You can now create convenience structures for invoking your Lambda functions.
## Step 4: Use Lambda helper functions with your Aurora PostgreSQL DB cluster (Optional)
You can use the helper functions in the `aws_commons` extension to prepare entities that you can more easily invoke from PostgreSQL. To do this, you need to have the following information about your Lambda functions:
+ **Function name** – The name, Amazon Resource Name (ARN), version, or alias of the Lambda function. The IAM policy created in [Step 2: Configure IAM for your cluster and Lambda](#PostgreSQL-Lambda-access) requires the ARN, so we recommend that you use your function's ARN.
+ **AWS Region** – (Optional) The AWS Region where the Lambda function is located if it's not in the same Region as your Aurora PostgreSQL DB cluster.
To hold the Lambda function name information, you use the [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn) function. This helper function creates an `aws_commons._lambda_function_arn_1` composite structure with the details needed by the invoke function. Following, you can find three alternative approaches to setting up this composite structure.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
Any of these values can be used in calls to the [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) function. For examples, see [Step 5: Invoke a Lambda function from your Aurora PostgreSQL DB cluster](#PostgreSQL-Lambda-invoke).
## Step 5: Invoke a Lambda function from your Aurora PostgreSQL DB cluster
The `aws_lambda.invoke` function behaves synchronously or asynchronously, depending on the `invocation_type`. The two alternatives for this parameter are `RequestResponse` (the default) and `Event`, as follows.
+ **`RequestResponse`** – This invocation type is *synchronous*. It's the default behavior when the call is made without specifying an invocation type. The response payload includes the results of the `aws_lambda.invoke` function. Use this invocation type when your workflow requires receiving results from the Lambda function before proceeding.
+ **`Event`** – This invocation type is *asynchronous*. The response doesn't include a payload containing results. Use this invocation type when your workflow doesn't need a result from the Lambda function to continue processing.
As a simple test of your setup, you can connect to your DB instance using `psql` and invoke an example function from the command line. Suppose that you have one of the basic functions set up on your Lambda service, such as the simple Python function shown in the following screenshot.
![\[Example Lambda function shown in the AWS CLI for AWS Lambda\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/lambda_simple_function.png)
**To invoke an example function**
1. Connect to your primary DB instance using `psql` or pgAdmin.
```
psql -h cluster.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Invoke the function using its ARN.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
The response looks as follows.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
If your invocation attempt doesn't succeed, see [Lambda function error messages](PostgreSQL-Lambda-errors.md).
## Step 6: Grant other users permission to invoke Lambda functions
At this point in the procedures, only you as `rds_superuser` can invoke your Lambda functions. To allow other users to invoke any functions that you create, you need to grant them permission.
**To grant others permission to invoke Lambda functions**
1. Connect to your primary DB instance using `psql` or pgAdmin.
```
psql -h cluster.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Run the following SQL commands:
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Examples: Invoking Lambda functions from your Aurora PostgreSQL DB cluster
Following, you can find several examples of calling the [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) function. Most of the examples use the composite structure `aws_lambda_arn_1` that you create in [Step 4: Use Lambda helper functions with your Aurora PostgreSQL DB cluster (Optional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) to simplify passing the function details. For an example of asynchronous invocation, see [Example: Asynchronous (Event) invocation of Lambda functions](#PostgreSQL-Lambda-Event). All the other examples listed use synchronous invocation.
To learn more about Lambda invocation types, see [Invoking Lambda functions](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) in the *AWS Lambda Developer Guide*. For more information about `aws_lambda_arn_1`, see [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [Example: Synchronous (RequestResponse) invocation of Lambda functions](#PostgreSQL-Lambda-RequestResponse)
+ [Example: Asynchronous (Event) invocation of Lambda functions](#PostgreSQL-Lambda-Event)
+ [Example: Capturing the Lambda execution log in a function response](#PostgreSQL-Lambda-log-response)
+ [Example: Including client context in a Lambda function](#PostgreSQL-Lambda-client-context)
+ [Example: Invoking a specific version of a Lambda function](#PostgreSQL-Lambda-function-version)
## Example: Synchronous (RequestResponse) invocation of Lambda functions
Following are two examples of a synchronous Lambda function invocation. The results of these `aws_lambda.invoke` function calls are the same.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
The parameters are described as follows:
+ `:'aws_lambda_arn_1'` – This parameter identifies the composite structure created in [Step 4: Use Lambda helper functions with your Aurora PostgreSQL DB cluster (Optional)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function), with the `aws_commons.create_lambda_function_arn` helper function. You can also create this structure inline within your `aws_lambda.invoke` call as follows.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` – The JSON payload to pass to the Lambda function.
+ `'RequestResponse'` – The Lambda invocation type.
## Example: Asynchronous (Event) invocation of Lambda functions
Following is an example of an asynchronous Lambda function invocation. The `Event` invocation type schedules the Lambda function invocation with the specified input payload and returns immediately. Use the `Event` invocation type in certain workflows that don't depend on the results of the Lambda function.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Example: Capturing the Lambda execution log in a function response
You can include the last 4 KB of the execution log in the function response by using the `log_type` parameter in your `aws_lambda.invoke` function call. By default, this parameter is set to `None`, but you can specify `Tail` to capture the results of the Lambda execution log in the response, as shown following.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Set the [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) function's `log_type` parameter to `Tail` to include the execution log in the response. The default value for the `log_type` parameter is `None`.
The `log_result` that's returned is a `base64` encoded string. You can decode the contents using a combination of the `decode` and `convert_from` PostgreSQL functions.
For more information about `log_type`, see [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Example: Including client context in a Lambda function
The `aws_lambda.invoke` function has a `context` parameter that you can use to pass information separate from the payload, as shown following.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
To include client context, use a JSON object for the [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) function's `context` parameter.
For more information about the `context` parameter, see the [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) reference.
## Example: Invoking a specific version of a Lambda function
You can specify a particular version of a Lambda function by including the `qualifier` parameter with the `aws_lambda.invoke` call. Following, you can find an example that does this using `'custom_version'` as an alias for the version.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
You can also supply a Lambda function qualifier with the function name details instead, as follows.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
For more information about `qualifier` and other parameters, see the [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) reference.
# Lambda function error messages
In the following list you can find information about error messages, with possible causes and solutions.
+ **VPC configuration issues**
VPC configuration issues can raise the following error messages when trying to connect:
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
A common cause for this error is improperly configured VPC security group. Make sure you have an outbound rule for TCP open on port 443 of your VPC security group so that your VPC can connect to the Lambda VPC.
+ **Lack of permissions needed to invoke Lambda functions**
If you see either of the following error messages, the user (role) invoking the function doesn't have proper permissions.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
A user (role) must be given specific grants to invoke Lambda functions. For more information, see [Step 6: Grant other users permission to invoke Lambda functions](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Improper handling of errors in your Lambda functions**
If a Lambda function throws an exception during request processing, `aws_lambda.invoke` fails with a PostgreSQL error such as the following.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Be sure to handle errors in your Lambda functions or in your PostgreSQL application.
# AWS Lambda function and parameter reference
Following is the reference for the functions and parameters to use for invoking Lambda with Aurora PostgreSQL .
**Topics**
+ [aws\$1lambda.invoke](#aws_lambda.invoke)
+ [aws\$1commons.create\$1lambda\$1function\$1arn](#aws_commons.create_lambda_function_arn)
+ [aws\$1lambda parameters](#aws_lambda.parameters)
## aws\$1lambda.invoke
Runs a Lambda function for an Aurora PostgreSQL DB cluster .
For more details about invoking Lambda functions, see also [Invoke](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) in the *AWS Lambda Developer Guide.*
**Syntax**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Input parameters
**function\$1name**
The identifying name of the Lambda function. The value can be the function name, an ARN, or a partial ARN. For a listing of possible formats, see [ Lambda function name formats](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) in the *AWS Lambda Developer Guide.*
*payload*
The input for the Lambda function. The format can be JSON or JSONB. For more information, see [JSON Types](https://www.postgresql.org/docs/current/datatype-json.html) in the PostgreSQL documentation.
*region*
(Optional) The Lambda Region for the function. By default, Aurora resolves the AWS Region from the full ARN in the `function_name` or it uses the Aurora PostgreSQL DB instance Region. If this Region value conflicts with the one provided in the `function_name` ARN, an error is raised.
*invocation\$1type*
The invocation type of the Lambda function. The value is case-sensitive. Possible values include the following:
+ `RequestResponse` – The default. This type of invocation for a Lambda function is synchronous and returns a response payload in the result. Use the `RequestResponse` invocation type when your workflow depends on receiving the Lambda function result immediately.
+ `Event` – This type of invocation for a Lambda function is asynchronous and returns immediately without a returned payload. Use the `Event` invocation type when you don't need results of the Lambda function before your workflow moves on.
+ `DryRun` – This type of invocation tests access without running the Lambda function.
*log\$1type*
The type of Lambda log to return in the `log_result` output parameter. The value is case-sensitive. Possible values include the following:
+ Tail – The returned `log_result` output parameter will include the last 4 KB of the execution log.
+ None – No Lambda log information is returned.
*context*
Client context in JSON or JSONB format. Fields to use include than `custom` and `env`.
*qualifier*
A qualifier that identifies a Lambda function's version to be invoked. If this value conflicts with one provided in the `function_name` ARN, an error is raised.Output parameters
*status\$1code*
An HTTP status response code. For more information, see [Lambda Invoke response elements](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) in the *AWS Lambda Developer Guide.*
*payload*
The information returned from the Lambda function that ran. The format is in JSON or JSONB.
*executed\$1version*
The version of the Lambda function that ran.
*log\$1result*
The execution log information returned if the `log_type` value is `Tail` when the Lambda function was invoked. The result contains the last 4 KB of the execution log encoded in Base64.
## aws\$1commons.create\$1lambda\$1function\$1arn
Creates an `aws_commons._lambda_function_arn_1` structure to hold Lambda function name information. You can use the results of the `aws_commons.create_lambda_function_arn` function in the `function_name` parameter of the aws\$1lambda.invoke [aws\$1lambda.invoke](#aws_lambda.invoke) function.
**Syntax**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Input parameters
*function\$1name*
A required text string containing the Lambda function name. The value can be a function name, a partial ARN, or a full ARN.
*region*
An optional text string containing the AWS Region that the Lambda function is in. For a listing of Region names and associated values, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
## aws\$1lambda parameters
In this table, you can find parameters associated with the `aws_lambda` function.
| Parameter | Description |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | This is a dynamic parameter and it sets the maximum wait time while connecting to AWS Lambda. The default values is `1000`. Allowed values for this parameter are 1 - 900000. |
| `aws_lambda.request_timeout_ms` | This is a dynamic parameter and it sets the maximum wait time while waiting for response from AWS Lambda. The default values is `3000`. Allowed values for this parameter are 1 - 900000. |
| `aws_lambda.endpoint_override` | Specifies the endpoint that can be used to connect to AWS Lambda. An empty string selects the default AWS Lambda endpoint for the region. You must restart the database for this static parameter change to take effect. |
# Publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs
You can configure your Aurora PostgreSQL DB cluster to export log data to Amazon CloudWatch Logs on a regular basis. When you do so, events from your Aurora PostgreSQL DB cluster's PostgreSQL log are automatically *published* to Amazon CloudWatch, as Amazon CloudWatch Logs. In CloudWatch, you can find the exported log data in a *Log group* for your Aurora PostgreSQL DB cluster. The log group contains one or more *log streams* that contain the events from the PostgreSQL log from each instance in the cluster.
Publishing the logs to CloudWatch Logs allows you to keep your cluster's PostgreSQL log records in highly durable storage. With the log data available in CloudWatch Logs, you can evaluate and improve your cluster's operations. You can also use CloudWatch to create alarms and view metrics. To learn more, see [Monitoring log events in Amazon CloudWatch](AuroraPostgreSQL.CloudWatch.Monitor.md).
**Note**
Publishing your PostgreSQL logs to CloudWatch Logs consumes storage, and you incur charges for that storage. Be sure to delete any CloudWatch Logs that you no longer need.
Turning the export log option off for an existing Aurora PostgreSQL DB cluster doesn't affect any data that's already held in CloudWatch Logs. Existing logs remain available in CloudWatch Logs based on your log retention settings. To learn more about CloudWatch Logs, see [What is Amazon CloudWatch Logs?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
Aurora PostgreSQL supports publishing logs to CloudWatch Logs for the following versions.
+ 16.1 and all higher versions
+ 15.2 and higher 15 versions
+ 14.3 and higher 14 versions
+ 13.3 and higher 13 versions
+ 12.8 and higher 12 versions
+ 11.9 and higher 11 versions
For information about turning on the option to publish logs to CloudWatch Logs, monitoring log events in CloudWatch Logs, and analyzing logs using CloudWatch Logs Insights, see the following topics.
**Topics**
+ [Turning on the option to publish logs to Amazon CloudWatch](AuroraPostgreSQL.CloudWatch.Publishing.md)
+ [Monitoring log events in Amazon CloudWatch](AuroraPostgreSQL.CloudWatch.Monitor.md)
+ [Analyzing PostgreSQL logs using CloudWatch Logs Insights](AuroraPostgreSQL.CloudWatch.Analyzing.md)
# Turning on the option to publish logs to Amazon CloudWatch
To publish your Aurora PostgreSQL DB cluster's PostgreSQL log to CloudWatch Logs, choose the **Log export** option for the cluster. You can choose the Log export setting when you create your Aurora PostgreSQL DB cluster. Or, you can modify the cluster later on. When you modify an existing cluster, its PostgreSQL logs from each instance are published to CloudWatch cluster from that point on. For Aurora PostgreSQL, the PostgreSQL log (`postgresql.log`) is the only log that gets published to Amazon CloudWatch.
You can use the AWS Management Console, the AWS CLI, or the RDS API to turn on the Log export feature for your Aurora PostgreSQL DB cluster.
## Console
You choose the Log exports option to start publishing the PostgreSQL logs from your Aurora PostgreSQL DB cluster to CloudWatch Logs.
**To turn on the Log export feature from the console**
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**.
1. Choose the Aurora PostgreSQL DB cluster whose log data you want to publish to CloudWatch Logs.
1. Choose **Modify**.
1. In the **Log exports** section, choose **PostgreSQL log**.
1. Choose **Continue**, and then choose **Modify cluster** on the summary page.
## AWS CLI
You can turn on the log export option to start publishing Aurora PostgreSQL logs to Amazon CloudWatch Logs with the AWS CLI. To do so, run the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command with the following options:
+ `--db-cluster-identifier`—The DB cluster identifier.
+ `--cloudwatch-logs-export-configuration`—The configuration setting for the log types to be set for export to CloudWatch Logs for the DB cluster.
You can also publish Aurora PostgreSQL logs by running one of the following AWS CLI commands:
+ [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
Run one of these AWS CLI commands with the following options:
+ `--db-cluster-identifier`—The DB cluster identifier.
+ `--engine`—The database engine.
+ `--enable-cloudwatch-logs-exports`—The configuration setting for the log types to be enabled for export to CloudWatch Logs for the DB cluster.
Other options might be required depending on the AWS CLI command that you run.
**Example**
The following command creates an Aurora PostgreSQL DB cluster to publish log files to CloudWatch Logs.
For Linux, macOS, or Unix:
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier my-db-cluster \
3. --engine aurora-postgresql \
4. --enable-cloudwatch-logs-exports postgresql
```
For Windows:
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier my-db-cluster ^
3. --engine aurora-postgresql ^
4. --enable-cloudwatch-logs-exports postgresql
```
**Example**
The following command modifies an existing Aurora PostgreSQL DB cluster to publish log files to CloudWatch Logs. The `--cloudwatch-logs-export-configuration` value is a JSON object. The key for this object is `EnableLogTypes`, and its value is `postgresql`, and `instance`.
For Linux, macOS, or Unix:
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier my-db-cluster \
3. --cloudwatch-logs-export-configuration '{"EnableLogTypes":["postgresql","instance"]}'
```
For Windows:
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier my-db-cluster ^
3. --cloudwatch-logs-export-configuration '{\"EnableLogTypes\":[\"postgresql\",\"instance\"]}'
```
When using the Windows command prompt, make sure to escape double quotation marks (") in JSON code by prefixing them with a backslash (\$1).
**Example**
The following example modifies an existing Aurora PostgreSQL DB cluster to disable publishing log files to CloudWatch Logs. The `--cloudwatch-logs-export-configuration` value is a JSON object. The key for this object is `DisableLogTypes`, and its value is `postgresql` and `instance`.
For Linux, macOS, or Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier mydbinstance \
--cloudwatch-logs-export-configuration '{"DisableLogTypes":["postgresql","instance"]}'
```
For Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier mydbinstance ^
--cloudwatch-logs-export-configuration "{\"DisableLogTypes\":[\"postgresql\",\"instance\"]}"
```
When using the Windows command prompt, you must escape double quotes (") in JSON code by prefixing them with a backslash (\$1).
## RDS API
You can turn on the log export option to start publishing Aurora PostgreSQL logs with the RDS API. To do so, run the [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) operation with the following options:
+ `DBClusterIdentifier` – The DB cluster identifier.
+ `CloudwatchLogsExportConfiguration` – The configuration setting for the log types to be enabled for export to CloudWatch Logs for the DB cluster.
You can also publish Aurora PostgreSQL logs with the RDS API by running one of the following RDS API operations:
+ [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)
+ [RestoreDBClusterFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [RestoreDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
Run the RDS API action with the following parameters:
+ `DBClusterIdentifier`—The DB cluster identifier.
+ `Engine`—The database engine.
+ `EnableCloudwatchLogsExports`—The configuration setting for the log types to be enabled for export to CloudWatch Logs for the DB cluster.
Other parameters might be required depending on the AWS CLI command that you run.
# Monitoring log events in Amazon CloudWatch
With Aurora PostgreSQL log events published and available as Amazon CloudWatch Logs, you can view and monitor events using Amazon CloudWatch. For more information about monitoring, see [View log data sent to CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData).
When you turn on Log exports, a new log group is automatically created using the prefix `/aws/rds/cluster/` with the name of your Aurora PostgreSQL and the log type, as in the following pattern.
```
/aws/rds/cluster/your-cluster-name/postgresql
```
As an example, suppose that an Aurora PostgreSQL DB cluster named `docs-lab-apg-small` exports its log to Amazon CloudWatch Logs. Its log group name in Amazon CloudWatch is shown following.
```
/aws/rds/cluster/docs-lab-apg-small/postgresql
```
If a log group with the specified name exists, Aurora uses that log group to export log data for the Aurora DB cluster. Each DB instance in the Aurora PostgreSQL DB cluster uploads its PostgreSQL log to the log group as a distinct log stream. You can examine the log group and its log streams using the various graphical and analytical tools available in Amazon CloudWatch.
For example, you can search for information within the log events from your Aurora PostgreSQL DB cluster, and filter events by using the CloudWatch Logs console, the AWS CLI, or the CloudWatch Logs API. For more information, [Searching and filtering log data](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) in the *Amazon CloudWatch Logs User Guide*.
By default, new log groups are created using **Never expire** for their retention period. You can use the CloudWatch Logs console, the AWS CLI, or the CloudWatch Logs API to change the log retention period. To learn more, see [Change log data retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) in the *Amazon CloudWatch Logs User Guide*.
**Tip**
You can use automated configuration, such as AWS CloudFormation, to create log groups with predefined log retention periods, metric filters, and access permissions.
# Analyzing PostgreSQL logs using CloudWatch Logs Insights
With the PostgreSQL logs from your Aurora PostgreSQL DB cluster published as CloudWatch Logs, you can use CloudWatch Logs Insights to interactively search and analyze your log data in Amazon CloudWatch Logs. CloudWatch Logs Insights includes a query language, sample queries, and other tools for analyzing your log data so that you can identify potential issues and verify fixes. To learn more, see [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) in the *Amazon CloudWatch Logs User Guide*.
**To analyze PostgreSQL logs with CloudWatch Logs Insights**
1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, open **Logs** and choose **Log insights**.
1. In **Select log group(s)**, select the log group for your Aurora PostgreSQL DB cluster.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-select-log-group.png)
1. In the query editor, delete the query that is currently shown, enter the following, and then choose **Run query**.
```
##Autovacuum execution time in seconds per 5 minute
fields @message
| parse @message "elapsed: * s" as @duration_sec
| filter @message like / automatic vacuum /
| display @duration_sec
| sort @timestamp
| stats avg(@duration_sec) as avg_duration_sec,
max(@duration_sec) as max_duration_sec
by bin(5 min)
```
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-query.png)
1. Choose the **Visualization** tab.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-visualization.png)
1. Choose **Add to dashboard**.
1. In **Select a dashboard**, either select a dashboard or enter a name to create a new dashboard.
1. In **Widget type**, choose a widget type for your visualization.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-dashboard.png)
1. (Optional) Add more widgets based on your log query results.
1. Choose **Add widget**.
1. Choose a widget type, such as **Line**.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-widget.png)
1. In the **Add to this dashboard** window, choose **Logs**.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-add-logs-to-dashboard.png)
1. In **Select log group(s)**, select the log group for your DB cluster.
1. In the query editor, delete the query that is currently shown, enter the following, and then choose **Run query**.
```
##Autovacuum tuples statistics per 5 min
fields @timestamp, @message
| parse @message "tuples: " as @tuples_temp
| parse @tuples_temp "* removed," as @tuples_removed
| parse @tuples_temp "remain, * are dead but not yet removable, " as @tuples_not_removable
| filter @message like / automatic vacuum /
| sort @timestamp
| stats avg(@tuples_removed) as avg_tuples_removed,
avg(@tuples_not_removable) as avg_tuples_not_removable
by bin(5 min)
```
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-query2.png)
1. Choose **Create widget**.
Your dashboard should look similar to the following image.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-cwl-insights-dashboard-two-graphs.png)
# Monitoring query execution plans and peak memory for Aurora PostgreSQL
You can monitor query execution plans in your Aurora PostgreSQL DB instance to detect the execution plans contributing to current database load and to track performance statistics of execution plans over time using the `aurora_compute_plan_id` parameter. Whenever a query executes, the execution plan used by the query is assigned an identifier and the same identifier is used by subsequent executions of the same plan.
The `aurora_compute_plan_id` is turned `OFF` by default in DB parameter group from Aurora PostgreSQL versions 14.10, 15.5, and higher versions. To assign a plan identifier, set `aurora_compute_plan_id` to `ON` in the parameter group.
This plan identifier is used in several utilities that serve a different purpose.
You can monitor query peak memory usage in your DB instance to detect queries contributing to high database memory use from the following versions:
+ 16.3 and all higher versions
+ 15.7 and higher versions
+ 14.12 and higher versions
Whenever a query runs, the peak memory used by the query is tracked. Queries typically run many times; the average, minimum and maximum memory usage values across all runs can be viewed for each query.
**Topics**
+ [Accessing query execution plans and peak memory using Aurora functions](#AuroraPostgreSQL.Monitoring.Query.Plans.Functions)
+ [Parameter reference for Aurora PostgreSQL query execution plans](#AuroraPostgreSQL.Monitoring.Query.Plans.Parameters)
## Accessing query execution plans and peak memory using Aurora functions
With `aurora_compute_plan_id`, you can access the execution plans using the following functions:
+ aurora\$1stat\$1activity
+ aurora\$1stat\$1plans
The query peak memory does not include memory that is allocated before query processing starts. Peak memory usage is tracked and reported separately for the planning and execution phases of each query.
![\[\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-apg-peakmemory.png)
You can access the query peak memory statistics using the following functions:
+ aurora\$1stat\$1statements
+ aurora\$1stat\$1plans
For more information on these functions, see [Aurora PostgreSQL functions reference](Appendix.AuroraPostgreSQL.Functions.md).
## Parameter reference for Aurora PostgreSQL query execution plans
You can monitor the query execution plans using the below parameters in a DB parameter group.
**Topics**
+ [aurora\$1compute\$1plan\$1id](#aurora.compute_plan_id)
+ [aurora\$1stat\$1plans.minutes\$1until\$1recapture](#aurora.minutes_until_recapture)
+ [aurora\$1stat\$1plans.calls\$1until\$1recapture](#aurora.calls_until_recapture)
+ [aurora\$1stat\$1plans.with\$1costs](#aurora.with_costs)
+ [aurora\$1stat\$1plans.with\$1analyze](#aurora.with_analyze)
+ [aurora\$1stat\$1plans.with\$1timing](#aurora.with_timing)
+ [aurora\$1stat\$1plans.with\$1buffers](#aurora.with_buffers)
+ [aurora\$1stat\$1plans.with\$1wal](#aurora.with_wal)
+ [aurora\$1stat\$1plans.with\$1triggers](#aurora.with_triggers)
**Note**
The configuration for `aurora_stat_plans.with_*` parameters takes effect only for newly captured plans.
### aurora\$1compute\$1plan\$1id
The `aurora_compute_plan_id` is a configuration parameter that controls whether a plan identifier is assigned during query execution.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
### aurora\$1stat\$1plans.minutes\$1until\$1recapture
The number of minutes to pass before a plan is recaptured. Default is 0 which will disable recapturing a plan. When the `aurora_stat_plans.calls_until_recapture` threshold is passed, the plan will be recaptured.
| Default | Allowed values | Description |
| --- | --- | --- |
| 0 | 0-1073741823 | Set the number of minutes to pass before a plan is recaptured. |
### aurora\$1stat\$1plans.calls\$1until\$1recapture
The number of calls to a plan before it is recaptured. Default is 0 which will disable recapturing a plan after a number of calls. When the `aurora_stat_plans.minutes_until_recapture` threshold is passed, the plan will be recaptured.
| Default | Allowed values | Description |
| --- | --- | --- |
| 0 | 0-1073741823 | Set the number of calls before a plan is recaptured. |
### aurora\$1stat\$1plans.with\$1costs
Captures an EXPLAIN plan with estimated costs. The allowed values are `on` and `off`. The default is `on`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
### aurora\$1stat\$1plans.with\$1analyze
Controls the EXPLAIN plan with ANALYZE. This mode is only used the first time a plan is captured. The allowed values are `on` and `off`. The default is `off`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
### aurora\$1stat\$1plans.with\$1timing
Plan timing will be captured in the explain when ANALYZE is used. The default is `on`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
### aurora\$1stat\$1plans.with\$1buffers
Plan buffer usage statistics will be captured in the explain when ANALYZE is used. The default is `off`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
### aurora\$1stat\$1plans.with\$1wal
Plan wal usage statistics will be captured in the explain when ANALYZE is used. The default is `off`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
### aurora\$1stat\$1plans.with\$1triggers
Plan trigger execution statistics will be captured in the explain when `ANALYZE` is used. The default is `off`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html)
# Managing query execution plans for Aurora PostgreSQL
Aurora PostgreSQL query plan management is an optional feature that you can use with your Amazon Aurora PostgreSQL-Compatible Edition DB cluster. This feature is packaged as the `apg_plan_mgmt` extension that you can install in your Aurora PostgreSQL DB cluster. Query plan management allows you to manage the query execution plans generated by the optimizer for your SQL applications. The `apg_plan_mgmt` AWS extension builds on the native query processing functionality of the PostgreSQL database engine.
Following, you can find information about Aurora PostgreSQL query plan management features, how to set it up, and how to use it with your Aurora PostgreSQL DB cluster. Before you get started, we recommend that you review any release notes for the specific version of the `apg_plan_mgmt` extension available for your Aurora PostgreSQL version. For more information, see [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in the *Release Notes for Aurora PostgreSQL*.
**Topics**
+ [Overview of Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.overview.md)
+ [Best practices for Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.BestPractice.md)
+ [Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.Start.md)
+ [Capturing Aurora PostgreSQL execution plans](AuroraPostgreSQL.Optimize.CapturePlans.md)
+ [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md)
+ [Examining Aurora PostgreSQL query plans in the dba\$1plans view](AuroraPostgreSQL.Optimize.ViewPlans.md)
+ [Improving Aurora PostgreSQL query plans](AuroraPostgreSQL.Optimize.Maintenance.md)
+ [Deleting Aurora PostgreSQL query plans](AuroraPostgreSQL.Optimize.Deleting.md)
+ [Exporting and importing managed plans for Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md)
+ [Parameter reference for Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.Parameters.md)
+ [Function reference for Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.Functions.md)
+ [Reference for the apg\$1plan\$1mgmt.dba\$1plans view for Aurora PostgreSQL-Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md)
+ [Advanced features in Query Plan Management](AuroraPostgreSQL.QPM.Advanced.md)
# Overview of Aurora PostgreSQL query plan management
Aurora PostgreSQL query plan management is designed to ensure plan stability regardless of changes to the database that might cause query plan regression. *Query plan regression* occurs when the optimizer chooses a sub-optimal plan for a given SQL statement after system or database changes. Changes to statistics, constraints, environment settings, query parameter bindings, and upgrades to the PostgreSQL database engine can all cause plan regression.
With Aurora PostgreSQL query plan management, you can control how and when query execution plans change. The benefits of Aurora PostgreSQL query plan management include the following.
+ Improve plan stability by forcing the optimizer to choose from a small number of known, good plans.
+ Optimize plans centrally and then distribute the best plans globally.
+ Identify indexes that aren't used and assess the impact of creating or dropping an index.
+ Automatically detect a new minimum-cost plan discovered by the optimizer.
+ Try new optimizer features with less risk, because you can choose to approve only the plan changes that improve performance.
You can use the tools provided by query plan management proactively, to specify the best plan for certain queries. Or you can use query plan management to react to changing circumstances and avoid plan regressions. For more information, see [Best practices for Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.BestPractice.md).
**Topics**
+ [Supported SQL statements](#AuroraPostgreSQL.Optimize.overview.features)
+ [Query plan management limitations](#AuroraPostgreSQL.Optimize.overview.limitations)
+ [Query plan management terminology](#AuroraPostgreSQL.Optimize.Start-terminology)
+ [Aurora PostgreSQL query plan management versions](#AuroraPostgreSQL.Optimize.overview.versions)
+ [Turning on Aurora PostgreSQL query plan management](#AuroraPostgreSQL.Optimize.Enable)
+ [Upgrading Aurora PostgreSQL query plan management](#AuroraPostgreSQL.Optimize.Upgrade)
+ [Turning off Aurora PostgreSQL query plan management](#AuroraPostgreSQL.Optimize.Enable.turnoff)
## Supported SQL statements
Query plan management supports the following types of SQL statements.
+ Any SELECT, INSERT, UPDATE, or DELETE statement, regardless of complexity.
+ Prepared statements. For more information, see [PREPARE](https://www.postgresql.org/docs/14/sql-prepare.html) in the PostgreSQL documentation.
+ Dynamic statements, including those run in immediate-mode. For more information, see [Dynamic SQL](https://www.postgresql.org/docs/current/ecpg-dynamic.html) and [EXECUTE IMMEDIATE](https://www.postgresql.org/docs/current/ecpg-sql-execute-immediate.html) in PostgreSQL documentation.
+ Embedded SQL commands and statements. For more information, see [Embedded SQL Commands](https://www.postgresql.org/docs/current/ecpg-sql-commands.html) in the PostgreSQL documentation.
+ Statements inside named functions. For more information, see [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) in the PostgreSQL documentation.
+ Statements containing temp tables.
+ Statements inside procedures and DO-blocks.
You can use query plan management with `EXPLAIN` in manual mode to capture a plan without actually running it. For more information, see [Analyzing the optimizer's chosen plan](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). To learn more about query plan management's modes (manual, automatic), see [Capturing Aurora PostgreSQL execution plans](AuroraPostgreSQL.Optimize.CapturePlans.md).
Aurora PostgreSQL query plan management supports all PostgreSQL language features, including partitioned tables, inheritance, row-level security, and recursive common table expressions (CTEs). To learn more about these PostgreSQL language features, see [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html), [Row Security Policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html), and [WITH Queries (Common Table Expressions)](https://www.postgresql.org/docs/current/queries-with.html) and other topics in the PostgreSQL documentation.
For information about different versions of the Aurora PostgreSQL query plan management feature, see [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in the *Release Notes for Aurora PostgreSQL*.
## Query plan management limitations
The current release of Aurora PostgreSQL query plan management has the following limitations.
+ **Plans aren't captured for statements that reference system relations** – Statements that reference system relations, such as `pg_class`, aren't captured. This is by design, to prevent a large number of system-generated plans that are used internally from being captured. This also applies to system tables inside views.
+ **Larger DB instance class might be needed for your Aurora PostgreSQL DB cluster** – Depending on the workload, query plan management might need a DB instance class that has more than 2 vCPUs. The number of `max_worker_processes` is limited by the DB instance class size. The number of `max_worker_processes` provided by a 2-vCPU DB instance class (db.t3.medium, for example) might not be sufficient for a given workload. We recommend that you choose a DB instance class with more than 2 vCPUs for your Aurora PostgreSQL DB cluster if you use query plan managment.
When the DB instance class can't support the workload, query plan management raises an error message such as the following.
```
WARNING: could not register plan insert background process
HINT: You may need to increase max_worker_processes.
```
In this case, you should scale up your Aurora PostgreSQL DB cluster to a DB instance class size with more memory. For more information, see [Supported DB engines for DB instance classes](Concepts.DBInstanceClass.SupportAurora.md).
+ **Plans already stored in sessions aren't affected** – Query plan management provides a way to influence query plans without changing the application code. However, when a generic plan is already stored in an existing session and if you want to change its query plan, then you must first set`plan_cache_mode` to `force_custom_plan` in the DB cluster parameter group.
+ `queryid` in `apg_plan_mgmt.dba_plans` and `pg_stat_statements` can diverge when:
+ Objects are dropped and recreated after storing in apg\$1plan\$1mgmt.dba\$1plans.
+ `apg_plan_mgmt.plans` table is imported from another cluster.
For information about different versions of the Aurora PostgreSQL query plan management feature, see [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in the *Release Notes for Aurora PostgreSQL*.
## Query plan management terminology
The following terms are used throughout this topic.
**managed statement**
A SQL statement captured by the optimizer under query plan management. A managed statement has one or more query execution plans stored in the `apg_plan_mgmt.dba_plans` view.
**plan baseline**
The set of approved plans for a given managed statement. That is, all the plans for the managed statement that have "Approved" for their `status` column in the `dba_plan` view.
**plan history**
The set of all captured plans for a given managed statement. The plan history contains all plans captured for the statement, regardless of status.
**query plan regression**
The case when the optimizer chooses a less optimal plan than it did before a given change to the database environment, such as a new PostgreSQL version or changes to statistics.
## Aurora PostgreSQL query plan management versions
Query plan management is supported by all currently available Aurora PostgreSQL releases. For more information, see the list of [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) in the *Release Notes for Aurora PostgreSQL*.
Query plan management functionality is added to your Aurora PostgreSQL DB cluster when you install the `apg_plan_mgmt` extension. Different versions of Aurora PostgreSQL support different versions of the `apg_plan_mgmt` extension. We recommend that you upgrade the query plan management extension to the latest release for your version of Aurora PostgreSQL.
**Note**
For release notes for each `apg_plan_mgmt` extension versions, see [Aurora PostgreSQL apg\$1plan\$1mgmt extension versions](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.apg_plan_mgmt) in the *Release Notes for Aurora PostgreSQL*.
You can identify the version running on your cluster by connecting to an instance using `psql` and using the metacommand \$1dx to list extensions as shown following.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------------+---------+---------------+-------------------------------------------------------------------
apg_plan_mgmt | 1.0 | apg_plan_mgmt | Amazon Aurora with PostgreSQL compatibility Query Plan Management
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)
```
The output shows that this cluster is using 1.0 version of the extension. Only certain `apg_plan_mgmt` versions are available for a given Aurora PostgreSQL version. In some cases, you might need to upgrade the Aurora PostgreSQL DB cluster to a new minor release or apply a patch so that you can upgrade to the most recent version of query plan management. The `apg_plan_mgmt` version 1.0 shown in the output is from an Aurora PostgreSQL version 10.17 DB cluster, which doesn't have a newer version of `apg_plan_mgmt` available. In this case, the Aurora PostgreSQL DB cluster should be upgraded to a more recent version of PostgreSQL.
For more information about upgrading your Aurora PostgreSQL DB cluster to a new version of PostgreSQL, see [Database engine updates for Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md).
To learn how to upgrade the `apg_plan_mgmt` extension, see [Upgrading Aurora PostgreSQL query plan management](#AuroraPostgreSQL.Optimize.Upgrade).
## Turning on Aurora PostgreSQL query plan management
Setting up query plan management for your Aurora PostgreSQL DB cluster involves installing an extension and changing several DB cluster parameter settings. You need `rds_superuser` permissions to install the `apg_plan_mgmt` extension and to turn on the feature for the Aurora PostgreSQL DB cluster.
Installing the extension creates a new role, `apg_plan_mgmt`. This role allows database users to view, manage, and maintain query plans. As an administrator with `rds_superuser` privileges, be sure to grant the `apg_plan_mgmt` role to database users as needed.
Only users with the `rds_superuser` role can complete the following procedure. The `rds_superuser` is required for creating the `apg_plan_mgmt` extension and its `apg_plan_mgmt` role. Users must be granted the `apg_plan_mgmt` role to administer the `apg_plan_mgmt` extension.
**To turn on query plan management for your Aurora PostgreSQL DB cluster**
The following steps turn on query plan management for all SQL statements that get submitted to the Aurora PostgreSQL DB cluster. This is known as *automatic* mode. To learn more about the difference between modes, see [Capturing Aurora PostgreSQL execution plans](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Create a custom DB cluster parameter group for your Aurora PostgreSQL DB cluster. You need to change certain parameters to activate query plan management and to set its behavior. For more information, see [Creating a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Creating.md).
1. Open the custom DB cluster parameter group and set the `rds.enable_plan_management` parameter to `1`, as shown in the following image.
![\[Image of the DB cluster parameter group.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-qpm-custom-db-cluster-param-change-1.png)
For more information, see [Modifying parameters in a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Create a custom DB parameter group that you can use to set query plan parameters at the instance level. For more information, see [Creating a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
1. Modify the writer instance of the Aurora PostgreSQL DB cluster to use the custom DB parameter group. For more information, see [Modifying a DB instance in a DB cluster](Aurora.Modifying.md#Aurora.Modifying.Instance).
1. Modify the Aurora PostgreSQL DB cluster to use the custom DB cluster parameter group. For more information, see [Modifying the DB cluster by using the console, CLI, and API](Aurora.Modifying.md#Aurora.Modifying.Cluster).
1. Reboot your DB instance to enable the custom parameter group settings.
1. Connect to your Aurora PostgreSQL DB cluster's DB instance endpoint using `psql` or `pgAdmin`. The following example uses the default `postgres` account for the `rds_superuser` role.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=my-db
```
1. Create the `apg_plan_mgmt` extension for your DB instance, as shown following.
```
labdb=> CREATE EXTENSION apg_plan_mgmt;
CREATE EXTENSION
```
**Tip**
Install the `apg_plan_mgmt` extension in the template database for your application. The default template database is named `template1`. To learn more, see [Template Databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html) in the PostgreSQL documentation.
1. Change the `apg_plan_mgmt.capture_plan_baselines` parameter to `automatic`. This setting causes the optimizer to generate plans for every SQL statement that is either planned or executed two or more times.
**Note**
Query plan management also has a *manual* mode that you can use for specific SQL statements. To learn more, see [Capturing Aurora PostgreSQL execution plans](AuroraPostgreSQL.Optimize.CapturePlans.md).
1. Change the value of `apg_plan_mgmt.use_plan_baselines` parameter to "on." This parameter causes the optimizer to choose a plan for the statement from its plan baseline. To learn more, see [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md).
**Note**
You can modify the value of either of these dynamic parameters for the session without needing to reboot the instance.
When your query plan management set up is complete, be sure to grant the `apg_plan_mgmt` role to any database users that need to view, manage, or maintain query plans.
## Upgrading Aurora PostgreSQL query plan management
We recommend that you upgrade the query plan management extension to the latest release for your version of Aurora PostgreSQL.
1. Connect to the writer instance of your Aurora PostgreSQL DB cluster as a user that has `rds_superuser` privileges. If you kept the default name when you set up your instance, you connect as `postgres` This example shows how to use `psql`, but you can also use pgAdmin if you prefer.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Run the following query to upgrade the extension.
```
ALTER EXTENSION apg_plan_mgmt UPDATE TO '2.1';
```
1. Use the [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) function to update the hashes of all plans. The optimizer validates all Approved, Unapproved, and Rejected plans to ensure that they's still viable plans for new version of the extension.
```
SELECT apg_plan_mgmt.validate_plans('update_plan_hash');
```
To learn more about using this function, see [Validating plans](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
1. Use the [apg\$1plan\$1mgmt.reload](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.reload) function to refresh any plans in the shared memory with the validated plans from the dba\$1plans view.
```
SELECT apg_plan_mgmt.reload();
```
To learn more about all functions available for query plan management, see [Function reference for Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.Functions.md).
## Turning off Aurora PostgreSQL query plan management
You can disable query plan management at any time by turning off the `apg_plan_mgmt.use_plan_baselines` and `apg_plan_mgmt.capture_plan_baselines`.
```
labdb=> SET apg_plan_mgmt.use_plan_baselines = off;
labdb=> SET apg_plan_mgmt.capture_plan_baselines = off;
```
# Best practices for Aurora PostgreSQL query plan management
Query plan management lets you control how and when query execution plans change. As a DBA, your main goals when using QPM include preventing regressions when there are changes to your database, and controlling whether to allow the optimizer to use a new plan. In the following, you can find some recommended best practices for using query plan management. Proactive and reactive plan management approaches differ in how and when new plans get approved for use.
**Contents**
+ [Proactive plan management to help prevent performance regression](#AuroraPostgreSQL.Optimize.BestPractice.Proactive)
+ [Ensuring plan stability after a major version upgrade](#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade)
+ [Reactive plan management to detect and repair performance regressions](#AuroraPostgreSQL.Optimize.BestPractice.Reactive)
## Proactive plan management to help prevent performance regression
To prevent plan performance regressions from occurring, you *evolve* plan baselines by running a procedure that compares the performance of newly discovered plans to the performance of the existing baseline of Approved plans, and then automatically approves the fastest set of plans as the new baseline. In this way, the baseline of plans improves over time as faster plans are discovered.
1. In a development environment, identify the SQL statements that have the greatest impact on performance or system throughput. Then capture the plans for these statements as described in [Manually capturing plans for specific SQL statements](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Manual) and [Automatically capturing plans](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Export the captured plans from the development environment and import them into the production environment. For more information, see [Exporting and importing managed plans for Aurora PostgreSQL](AuroraPostgreSQL.Optimize.Maintenance.ExportingImporting.md).
1. In production, run your application and enforce the use of approved managed plans. For more information, see [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md). While the application runs, also add new plans as the optimizer discovers them. For more information, see [Automatically capturing plans](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Analyze the unapproved plans and approve those that perform well. For more information, see [Evaluating plan performance](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. While your application continues to run, the optimizer begins to use the new plans as appropriate.
### Ensuring plan stability after a major version upgrade
Each major version of PostgreSQL includes enhancements and changes to the query optimizer that are designed to improve performance. However, query execution plans generated by the optimizer in earlier versions might cause performance regressions in newer upgraded versions. You can use query plan management to resolve these performance issues and to ensure plan stability after a major version upgrade.
The optimizer always uses a minimum-cost Approved plan, even if more than one Approved plan for the same statement exists. After an upgrade the optimizer might discover new plans but they will be saved as Unapproved plans. These plans are performed only if approved using the reactive style of plan management with the unapproved\$1plan\$1execution\$1threshold parameter. You can maximize plan stability using the proactive style of plan management with the evolve\$1plan\$1baselines parameter. This compares the performance of the new plans to the old plans and approves or rejects plans that are at least 10% faster than the next best plan.
After upgrading, you can use the `evolve_plan_baselines` function to compare plan performance before and after the upgrade using your query parameter bindings. The following steps assume that you have been using approved managed plans in your production environment, as detailed in [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md).
1. Before upgrading, run your application with the query plan manager running. While the application runs, add new plans as the optimizer discovers them. For more information, see [Automatically capturing plans](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Evaluate each plan's performance. For more information, see [Evaluating plan performance](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
1. After upgrading, analyze your approved plans again using the `evolve_plan_baselines` function. Compare performance before and after using your query parameter bindings. If the new plan is fast, you can add it to your approved plans. If it's faster than another plan for the same parameter bindings, then you can mark the slower plan as Rejected.
For more information, see [Approving better plans](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Approving). For reference information about this function, see [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines).
For more information, see [Ensuring consistent performance after major version upgrades with Amazon Aurora PostgreSQL-Compatible Edition Query Plan Management](https://aws.amazon.com/blogs/database/ensuring-consistent-performance-after-major-version-upgrades-with-amazon-aurora-postgresql-query-plan-management/).
**Note**
When you perform a major version upgrade using logical replication or AWS DMS, make sure that you replicate the `apg_plan_mgmt` schema to ensure existing plans are copied to the upgraded instance. For more information on logical replication, see [Using logical replication to perform a major version upgrade for Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
## Reactive plan management to detect and repair performance regressions
By monitoring your application as it runs, you can detect plans that cause performance regressions. When you detect regressions, you manually reject or fix the bad plans by following these steps:
1. While your application runs, enforce the use of managed plans and automatically add newly discovered plans as unapproved. For more information, see [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md) and [Automatically capturing plans](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
1. Monitor your running application for performance regressions.
1. When you discover a plan regression, set the plan's status to `rejected`. The next time the optimizer runs the SQL statement, it automatically ignores the rejected plan and uses a different approved plan instead. For more information, see [Rejecting or disabling slower plans](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance.Rejecting).
In some cases, you might prefer to fix a bad plan rather than reject, disable, or delete it. Use the `pg_hint_plan` extension to experiment with improving a plan. With `pg_hint_plan`, you use special comments to tell the optimizer to override how it normally creates a plan. For more information, see [Fixing plans using pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan).
# Aurora PostgreSQL query plan management
With query plan management turned on for your Aurora PostgreSQL DB cluster, the optimizer generates and stores query execution plans for any SQL statement that it processes more than once. The optimizer always sets the status of a managed statement's first generated plan to `Approved`, and stores it in the `dba_plans` view.
The set of approved plans saved for a managed statement is known as its *plan baseline*. As your application runs, the optimizer might generate additional plans for managed statements. The optimizer sets additional captured plans to a status of `Unapproved`.
Later, you can decide if the `Unapproved` plans perform well and change them to `Approved`, `Rejected`, or `Preferred`. To do so, you use the `apg_plan_mgmt.evolve_plan_baselines` function or the `apg_plan_mgmt.set_plan_status` function.
When the optimizer generates a plan for a SQL statement, query plan management saves the plan in the `apg_plan_mgmt.plans` table. Database users that have been granted the `apg_plan_mgmt` role can see the plan details by querying the `apg_plan_mgmt.dba_plans` view. For example, the following query lists details for plans currently in the view for a non-production Aurora PostgreSQL DB cluster.
+ `sql_hash` – An identifier for the SQL statement that's the hash value for the normalized text of the SQL statement.
+ `plan_hash` – A unique identifier for the plan that's a combination of the `sql_hash` and a hash of the plan.
+ `status` – The status of the plan. The optimizer can run an approved plan.
+ `enabled` – Indicates whether the plan is ready to use (true) or not (false).
+ `plan_outline` – A representation of the plan that's used to recreate the actual execution plan. Operators in the tree structure map to operators in EXPLAIN output.
The `apg_plan_mgmt.dba_plans` view has many more columns that contain all details of the plan, such as when the plan was last used. For complete details, see [Reference for the apg\$1plan\$1mgmt.dba\$1plans view for Aurora PostgreSQL-Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
## Normalization and the SQL hash
In the `apg_plan_mgmt.dba_plans` view, you can identify a managed statement by its SQL hash value. The SQL hash is calculated on a normalized representation of the SQL statement that removes some differences, such as literal values.
The *normalization* process for each SQL statement preserves space and case, so that you can still read and understand the gist of the SQL statement. Normalization removes or replaces the following items.
+ Leading block comments
+ The EXPLAIN keyword and EXPLAIN options, and EXPLAIN ANALYZE
+ Trailing spaces
+ All literals
As an example, take the following statement.
```
/*Leading comment*/ EXPLAIN SELECT /* Query 1 */ * FROM t WHERE x > 7 AND y = 1;
```
The query plan management normalizes this statement as shown:
```
SELECT /* Query 1 */ * FROM t WHERE x > CONST AND y = CONST;
```
Normalization allows the same SQL hash to be used for similar SQL statements that might differ only in their literal or parameter values. In other words, multiple plans for the same SQL hash can exist, with a different plan that's optimal under different conditions.
**Note**
A single SQL statement that's used with different schemas has different plans because it's bound to the specific schema at runtime. The planner uses the statistics for schema binding to choose the optimal plan.
To learn more about how the optimizer chooses a plan, see [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md). In that section, you can learn how to use `EXPLAIN` and `EXPLAIN ANALYZE` to preview a plan before it's actually used. For details, see [Analyzing the optimizer's chosen plan](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.AnalyzePlans). For an image that outlines the process for choosing a plan, see [How the optimizer chooses which plan to run](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
# Capturing Aurora PostgreSQL execution plans
Aurora PostgreSQL query plan management offers two different modes for capturing query execution plans, automatic or manual. You choose the mode by setting the value of the `apg_plan_mgmt.capture_plans_baselines` to `automatic` or to `manual`. You can capture execution plans for specific SQL statements by using manual plan capture. Alternatively, you can capture all (or the slowest) plans that are executed two or more times as your application runs by using automatic plan capture.
When capturing plans, the optimizer sets the status of a managed statement's first captured plan to `approved`. The optimizer sets the status of any additional plans captured for a managed statement to `unapproved`. However, more than one plan might occasionally be saved with the `approved` status. This can happen when multiple plans are created for a statement in parallel and before the first plan for the statement is committed.
To control the maximum number of plans that can be captured and stored in the `dba_plans` view, set the `apg_plan_mgmt.max_plans` parameter in your DB instance-level parameter group. A change to the `apg_plan_mgmt.max_plans` parameter requires a DB instance reboot for a new value to take effect. For more information, see the [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans) parameter.
## Manually capturing plans for specific SQL statements
If you have a known set of SQL statements to manage, put the statements into a SQL script file and then manually capture plans. The following shows a psql example of how to capture query plans manually for a set of SQL statements.
```
psql> SET apg_plan_mgmt.capture_plan_baselines = manual;
psql> \i my-statements.sql
psql> SET apg_plan_mgmt.capture_plan_baselines = off;
```
After capturing a plan for each SQL statement, the optimizer adds a new row to the `apg_plan_mgmt.dba_plans` view.
We recommend that you use either EXPLAIN or EXPLAIN EXECUTE statements in the SQL script file. Make sure that you include enough variations in parameter values to capture all the plans of interest.
If you know of a better plan than the optimizer's minimum cost plan, you might be able to force the optimizer to use the better plan. To do so, specify one or more optimizer hints. For more information, see [Fixing plans using pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). To compare the performance of the `unapproved` and `approved` plans and approve, reject, or delete them, see [Evaluating plan performance](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## Automatically capturing plans
Use automatic plan capture for situations such as the following:
+ You don't know the specific SQL statements that you want to manage.
+ You have hundreds or thousands of SQL statements to manage.
+ Your application uses a client API. For example, JDBC uses unnamed prepared statements or bulk-mode statements that can't be expressed in psql.
**To capture plans automatically**
1. Turn on automatic plan capture by setting `apg_plan_mgmt.capture_plan_baselines` to `automatic` in the DB instance-level parameter group. For more information, see [Modifying parameters in a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
1. As the application runs, the optimizer captures plans for each SQL statement that runs at least twice.
As the application runs with default query plan management parameter settings, the optimizer captures plans for each SQL statement that runs at least twice. Capturing all plans while using the defaults has very little run-time overhead and can be enabled in production.
**To turn off automatic plan capture**
+ Set the `apg_plan_mgmt.capture_plan_baselines` parameter to `off` from the DB instance-level parameter group.
To measure the performance of the unapproved plans and approve, reject, or delete them, see [Evaluating plan performance](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
# Using Aurora PostgreSQL managed plans
To get the optimizer to use captured plans for your managed statements, set the parameter `apg_plan_mgmt.use_plan_baselines` to `true`. The following is a local instance example.
```
SET apg_plan_mgmt.use_plan_baselines = true;
```
While the application runs, this setting causes the optimizer to use the minimum-cost, preferred, or approved plan that is valid and enabled for each managed statement.
## Analyzing the optimizer's chosen plan
When the `apg_plan_mgmt.use_plan_baselines` parameter is set to `true`, you can use EXPLAIN ANALYZE SQL statements to cause the optimizer to show the plan it would use if it were to run the statement. The following is an example.
```
EXPLAIN ANALYZE EXECUTE rangeQuery (1,10000);
```
```
QUERY PLAN
--------------------------------------------------------------------------
Aggregate (cost=393.29..393.30 rows=1 width=8) (actual time=7.251..7.251 rows=1 loops=1)
-> Index Only Scan using t1_pkey on t1 t (cost=0.29..368.29 rows=10000 width=0) (actual time=0.061..4.859 rows=10000 loops=1)
Index Cond: ((id >= 1) AND (id <= 10000))
Heap Fetches: 10000
Planning time: 1.408 ms
Execution time: 7.291 ms
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1984047223, Plan Hash: 512153379
```
The output shows the Approved plan from the baseline that would run. However, the output also shows that it found a lower-cost plan. In this case, you capture this new minimum cost plan by turning on automatic plan capture as described in [Automatically capturing plans](AuroraPostgreSQL.Optimize.CapturePlans.md#AuroraPostgreSQL.Optimize.CapturePlans.Automatic).
New plans are always captured by the optimizer as `Unapproved`. Use the `apg_plan_mgmt.evolve_plan_baselines` function to compare plans and change them to approved, rejected, or disabled. For more information, see [Evaluating plan performance](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance).
## How the optimizer chooses which plan to run
The cost of an execution plan is an estimate that the optimizer makes to compare different plans. When calculating a plan's cost, the optimizer includes factors such as CPU and I/O operations required by that plan. To learn more about PostgreSQL query planner cost estimates, see [Query Planning](https://www.postgresql.org/docs/current/runtime-config-query.html) in the PostgreSQL documentation.
The following image shows how a plan is chosen for a given SQL statement when query plan management is active, and when it's not.
![\[Aurora PostgreSQL query plan management workflow\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-query-plan-mgmt_processing-flow.png)
The flow is as follows:
1. The optimizer generates a minimum-cost plan for the SQL statement.
1. If query plan management isn't active, the optimizer's plan is run immediately (A. Run Optimizer's plan). Query plan management is inactive when the `apg_plan_mgmt.capture_plan_baselines` and the `apg_plan_mgmt.use_plan_baselines` parameters are both at their default settings ("off" and "false," respectively).
Otherwise, query plan management is active. In this case, the SQL statement and the optimizer's plan for it are further assessed before a plan is chosen.
**Tip**
Database users with the `apg_plan_mgmt` role can pro-actively compare plans, change status of plans, and force the use of specific plans as needed. For more information, see [Improving Aurora PostgreSQL query plans](AuroraPostgreSQL.Optimize.Maintenance.md).
1. The SQL statement might already have plans that were stored by query plan management in the past. Plans are stored in the `apg_plan_mgmt.dba_plans`, along with information about the SQL statements that were used to create them. Information about a plan includes its status. A plan's status can determine whether it's used or not, as follows.
1. If the plan isn't among the stored plans for the SQL statement, it means that it's the first time this particular plan was generated by the optimizer for the given SQL statement. The plan is sent to Capture Plan Processing (4).
1. If the plan is among the stored plans and its status is Approved or Preferred, the plan is run (A. Run Optimizer's plan).
If the plan is among the stored plans but it's neither Approved nor Preferred, the plan is sent to Capture Plan Processing (4).
1. When a plan is captured for the first time for a given SQL statement, the plan's status is always set to Approved (P1). If the optimizer subsequently generates the same plan for the same SQL statement, the status of that plan is changed to Unapproved (P1\$1n).
With the plan captured and its status updated, the evaluation continues at the next step (5).
1. A plan's *baseline* consists of the history of the SQL statement and its plans at various states. Query plan management can take the baseline into account when choosing a plan, depending on whether the use plan baselines option is turned on or not, as follows.
+ Use plan baselines is "off" when the `apg_plan_mgmt.use_plan_baselines` parameter is set to its default value (`false`). The plan isn't compared to the baseline before it's run (A. Run Optimizer's plan).
+ Use plan baselines is "on" when the `apg_plan_mgmt.use_plan_baselines` parameter is set to `true`. The plan is further assessed using the baseline (6).
1. The plan is compared to other plans for the statement in the baseline.
1. If the optimizer's plan is among the plans in the baseline, its status is checked (7a).
1. If the optimizer's plan isn't among plans in the baseline, the plan is added to the plans for the statement as a new `Unapproved` plan.
1. The plan's status is checked to determine only if it's Unapproved.
1. If the plan's status is Unapproved, the plan's estimated cost is compared to the cost estimate specified for the unapproved execution plan threshold.
+ If the plan's estimated cost is below the threshold, the optimizer uses it even though it's an Unapproved plan (A. Run Optimizer's plan). Generally, the optimizer won't run an Unapproved plan. However, when the `apg_plan_mgmt.unapproved_plan_execution_threshold` parameter specifies a cost threshold value, the optimizer compares the Unapproved plan's cost to the threshold. If the estimated cost is less than the threshold, the optimizer runs the plan. For more information, see [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold).
+ If the plan's estimated cost isn't below the threshold, the plan's other attributes are checked (8a).
1. If the plan's status is anything other than Unapproved, its other attributes are checked (8a).
1. The optimizer won't use a plan that's disabled. That is, the plan that has its `enable` attribute set to 'f' (false). The optimizer also won't use a plan that has a status of Rejected.
The optimizer can't use any plans that aren't valid. Plans can become invalid over time when the objects that they depend on, such as indexes and table partitions, are removed or deleted.
1. If the statement has any enabled and valid Preferred plans, the optimizer chooses the minimum-cost plan from among the Preferred plans stored for this SQL statement. The optimizer then runs the minimum-cost Preferred plan.
1. If the statement doesn't have any enabled and valid Preferred plans, it's assessed in the next step (9).
1. If the statement has any enabled and valid Approved plans, the optimizer chooses the minimum-cost plan from among the Approved plans stored for this SQL statement. The optimizer then runs the minimum-cost Approved plan.
If the statement doesn't have any valid and enabled Approved plans, the optimizer uses the minimum cost plan (A. Run Optimizer's plan).
# Examining Aurora PostgreSQL query plans in the dba\$1plans view
Database users and administrators that have been granted the `apg_plan_mgmt` role can view and manage the plans stored in the `apg_plan_mgmt.dba_plans`. An Aurora PostgreSQL DB cluster's administrator (someone with `rds_superuser` permissions) must explicitly grant this role to the database users who need to work with query plan management.
The `apg_plan_mgmt` view contains the plan history for all managed SQL statements for every database on the writer instance of the Aurora PostgreSQL DB cluster. This view lets you examine plans, their state, when last used, and all other relevant details.
As discussed in [Normalization and the SQL hash](AuroraPostgreSQL.Optimize.Start.md#AuroraPostgreSQL.Optimize.Start.hash-and-normalization), each managed plan is identified by the combined SQL hash value and a plan hash value. With these identifiers, you can use tools such as Amazon RDS Performance Insights to track individual plan performance. For more information about Performance Insights, see [Using Amazon RDS performance insights]( https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html).
## Listing managed plans
To list the managed plans, use a SELECT statement on the `apg_plan_mgmt.dba_plans` view. The following example displays some columns in the `dba_plans` view such as the `status`, which identifies the approved and unapproved plans.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+------------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Unapproved | t | rangequery
(2 rows)
```
For readability, the query and the output shown list just a few of the columns from the `dba_plans` view. For complete information, see [Reference for the apg\$1plan\$1mgmt.dba\$1plans view for Aurora PostgreSQL-Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md).
# Improving Aurora PostgreSQL query plans
Improve query plan management by evaluating plan performance and fixing plans. For more information about improving your query plans, see the following topics.
**Topics**
+ [Evaluating plan performance](#AuroraPostgreSQL.Optimize.Maintenance.EvaluatingPerformance)
+ [Fixing plans using pg\$1hint\$1plan](#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan)
## Evaluating plan performance
After the optimizer captures plans as unapproved, use the `apg_plan_mgmt.evolve_plan_baselines` function to compare plans based on their actual performance. Depending on the outcome of your performance experiments, you can change a plan's status from unapproved to either approved or rejected. You can instead decide to use the `apg_plan_mgmt.evolve_plan_baselines` function to temporarily disable a plan if it does not meet your requirements.
### Approving better plans
The following example demonstrates how to change the status of managed plans to approved using the `apg_plan_mgmt.evolve_plan_baselines` function.
```
SELECT apg_plan_mgmt.evolve_plan_baselines (
sql_hash,
plan_hash,
min_speedup_factor := 1.0,
action := 'approve'
)
FROM apg_plan_mgmt.dba_plans WHERE status = 'Unapproved';
```
```
NOTICE: rangequery (1,10000)
NOTICE: Baseline [ Planning time 0.761 ms, Execution time 13.261 ms]
NOTICE: Baseline+1 [ Planning time 0.204 ms, Execution time 8.956 ms]
NOTICE: Total time benefit: 4.862 ms, Execution time benefit: 4.305 ms
NOTICE: Unapproved -> Approved
evolve_plan_baselines
-----------------------
0
(1 row)
```
The output shows a performance report for the `rangequery` statement with parameter bindings of 1 and 10,000. The new unapproved plan (`Baseline+1`) is better than the best previously approved plan (`Baseline`). To confirm that the new plan is now `Approved`, check the `apg_plan_mgmt.dba_plans` view.
```
SELECT sql_hash, plan_hash, status, enabled, stmt_name
FROM apg_plan_mgmt.dba_plans;
```
```
sql_hash | plan_hash | status | enabled | stmt_name
------------+-----------+----------+---------+------------
1984047223 | 512153379 | Approved | t | rangequery
1984047223 | 512284451 | Approved | t | rangequery
(2 rows)
```
The managed plan now includes two approved plans that are the statement's plan baseline. You can also call the `apg_plan_mgmt.set_plan_status` function to directly set a plan's status field to `'Approved'`, `'Rejected'`, `'Unapproved'`, or `'Preferred'`.
### Rejecting or disabling slower plans
To reject or disable plans, pass `'reject'` or `'disable' `as the action parameter to the `apg_plan_mgmt.evolve_plan_baselines` function. This example disables any captured `Unapproved` plan that is slower by at least 10 percent than the best `Approved` plan for the statement.
```
SELECT apg_plan_mgmt.evolve_plan_baselines(
sql_hash, -- The managed statement ID
plan_hash, -- The plan ID
1.1, -- number of times faster the plan must be
'disable' -- The action to take. This sets the enabled field to false.
)
FROM apg_plan_mgmt.dba_plans
WHERE status = 'Unapproved' AND -- plan is Unapproved
origin = 'Automatic'; -- plan was auto-captured
```
You can also directly set a plan to rejected or disabled. To directly set a plan's enabled field to `true` or `false`, call the `apg_plan_mgmt.set_plan_enabled` function. To directly set a plan's status field to `'Approved'`, `'Rejected'`, `'Unapproved'`, or `'Preferred'`, call the `apg_plan_mgmt.set_plan_status` function.
To delete plans that aren't valid and that you expect to remain invalid, use the `apg_plan_mgmt.validate_plans` function. This function lets you delete or disable invalid plans. For more information, see [Validating plans](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
## Fixing plans using pg\$1hint\$1plan
The query optimizer is well-designed to find an optimal plan for all statements, and in most cases the optimizer finds a good plan. However, occasionally you might know that a much better plan exists than that generated by the optimizer. Two recommended ways to get the optimizer to generate a desired plan include using the `pg_hint_plan` extension or setting Grand Unified Configuration (GUC) variables in PostgreSQL:
+ `pg_hint_plan` extension – Specify a "hint" to modify how the planner works by using PostgreSQL's `pg_hint_plan` extension. To install and learn more about how to use the `pg_hint_plan` extension, see the [pg\$1hint\$1plan documentation](https://github.com/ossc-db/pg_hint_plan).
+ GUC variables – Override one or more cost model parameters or other optimizer parameters, such as the `from_collapse_limit` or `GEQO_threshold`.
When you use one of these techniques to force the query optimizer to use a plan, you can also use query plan management to capture and enforce use of the new plan.
You can use the `pg_hint_plan` extension to change the join order, the join methods, or the access paths for a SQL statement. You use a SQL comment with special `pg_hint_plan` syntax to modify how the optimizer creates a plan. For example, assume the problem SQL statement has a two-way join.
```
SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
Then suppose that the optimizer chooses the join order (t1, t2), but you know that the join order (t2, t1) is faster. The following hint forces the optimizer to use the faster join order, (t2, t1). Include EXPLAIN so that the optimizer generates a plan for the SQL statement but without running the statement. (Output not shown.)
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
The following steps show how to use `pg_hint_plan`.
**To modify the optimizer's generated plan and capture the plan using pg\$1hint\$1plan**
1. Turn on the manual capture mode.
```
SET apg_plan_mgmt.capture_plan_baselines = manual;
```
1. Specify a hint for the SQL statement of interest.
```
/*+ Leading ((t2 t1)) */ EXPLAIN SELECT *
FROM t1, t2
WHERE t1.id = t2.id;
```
After this runs, the optimizer captures the plan in the `apg_plan_mgmt.dba_plans` view. The captured plan doesn't include the special `pg_hint_plan` comment syntax because query plan management normalizes the statement by removing leading comments.
1. View the managed plans by using the `apg_plan_mgmt.dba_plans` view.
```
SELECT sql_hash, plan_hash, status, sql_text, plan_outline
FROM apg_plan_mgmt.dba_plans;
```
1. Set the status of the plan to `Preferred`. Doing so makes sure that the optimizer chooses to run it, instead of selecting from the set of approved plans, when the minimum-cost plan isn't already `Approved` or `Preferred`.
```
SELECT apg_plan_mgmt.set_plan_status(sql-hash, plan-hash, 'preferred' );
```
1. Turn off manual plan capture and enforce the use of managed plans.
```
SET apg_plan_mgmt.capture_plan_baselines = false;
SET apg_plan_mgmt.use_plan_baselines = true;
```
Now, when the original SQL statement runs, the optimizer chooses either an `Approved` or `Preferred` plan. If the minimum-cost plan isn't `Approved` or `Preferred`, then the optimizer chooses the `Preferred` plan.
# Deleting Aurora PostgreSQL query plans
Delete execution plans that you aren't using or plans that aren't valid. For more information about deleting plans, see the following sections.
**Topics**
+ [Deleting plans](#AuroraPostgreSQL.Optimize.Maintenance.DeletingPlans)
+ [Validating plans](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
## Deleting plans
Plans are automatically deleted if they haven't been used in over a month, specifically, 32 days. That's the default setting for the `apg_plan_mgmt.plan_retention_period` parameter. You can change the plan retention period to a longer period of time, or to a shorter period of time starting from the value of 1. Determining the number of days since a plan was last used is calculated by subtracting the `last_used` date from the current date. The `last_used` date is the most recent date that the optimizer chose the plan as the minimum cost plan or that the plan was run. The date is stored for the plan in the `apg_plan_mgmt.dba_plans` view.
We recommend that you delete plans that haven't been used for a long time or that aren't useful. Every plan has a `last_used` date that the optimizer updates each time it executes a plan or chooses the plan as the minimum-cost plan for a statement. Check the last `last_used` dates to identify the plans that you can safely delete.
The following query returns a three column table with the count on the total number of plans, plans failed to delete, and the plans successfully deleted. It has a nested query that is an example of how to use the `apg_plan_mgmt.delete_plan` function to delete all plans that haven't been chosen as the minimum-cost plan in the last 31 days and its status is not `Rejected`.
```
SELECT (SELECT COUNT(*) from apg_plan_mgmt.dba_plans) total_plans,
COUNT(*) FILTER (WHERE result = -1) failed_to_delete,
COUNT(*) FILTER (WHERE result = 0) successfully_deleted
FROM (
SELECT apg_plan_mgmt.delete_plan(sql_hash, plan_hash) as result
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '31 days')
AND status <> 'Rejected'
) as dba_plans ;
```
```
total_plans | failed_to_delete | successfully_deleted
-------------+------------------+----------------------
3 | 0 | 2
```
For more information, see [apg\$1plan\$1mgmt.delete\$1plan](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.delete_plan).
To delete plans that aren't valid and that you expect to remain invalid, use the `apg_plan_mgmt.validate_plans` function. This function lets you delete or disable invalid plans. For more information, see [Validating plans](#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans).
**Important**
If you don't delete extraneous plans, you might eventually run out of shared memory that's set aside for query plan management. To control how much memory is available for managed plans, use the `apg_plan_mgmt.max_plans` parameter. Set this parameter in your custom DB parameter group and reboot your DB instance for changes to take effect. For more information, see the [apg\$1plan\$1mgmt.max\$1plans](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.max_plans) parameter.
## Validating plans
Use the `apg_plan_mgmt.validate_plans` function to delete or disable plans that are invalid.
Plans can become invalid or stale when objects that they depend on are removed, such as an index or a table. However, a plan might be invalid only temporarily if the removed object gets recreated. If an invalid plan can become valid later, you might prefer to disable an invalid plan or do nothing rather than delete it.
To find and delete all plans that are invalid and haven't been used in the past week, use the `apg_plan_mgmt.validate_plans `function as follows.
```
SELECT apg_plan_mgmt.validate_plans(sql_hash, plan_hash, 'delete')
FROM apg_plan_mgmt.dba_plans
WHERE last_used < (current_date - interval '7 days');
```
To enable or disabled a plan directly, use the `apg_plan_mgmt.set_plan_enabled` function.
# Exporting and importing managed plans for Aurora PostgreSQL
You can export your managed plans and import them into another DB instance.
**To export managed plans**
An authorized user can copy any subset of the `apg_plan_mgmt.plans` table to another table, and then save it using the `pg_dump` command. The following is an example.
```
CREATE TABLE plans_copy AS SELECT *
FROM apg_plan_mgmt.plans [ WHERE predicates ] ;
```
```
% pg_dump --table apg_plan_mgmt.plans_copy -Ft mysourcedatabase > plans_copy.tar
```
```
DROP TABLE apg_plan_mgmt.plans_copy;
```
**To import managed plans**
1. Copy the .tar file of the exported managed plans to the system where the plans are to be restored.
1. Use the `pg_restore` command to copy the tar file into a new table.
```
% pg_restore --dbname mytargetdatabase -Ft plans_copy.tar
```
1. Merge the `plans_copy` table with the `apg_plan_mgmt.plans` table, as shown in the following example.
**Note**
In some cases, you might dump from one version of the `apg_plan_mgmt` extension and restore into a different version. In these cases, the columns in the plans table might be different. If so, name the columns explicitly instead of using SELECT \$1.
```
INSERT INTO apg_plan_mgmt.plans SELECT * FROM plans_copy
ON CONFLICT ON CONSTRAINT plans_pkey
DO UPDATE SET
status = EXCLUDED.status,
enabled = EXCLUDED.enabled,
-- Save the most recent last_used date
--
last_used = CASE WHEN EXCLUDED.last_used > plans.last_used
THEN EXCLUDED.last_used ELSE plans.last_used END,
-- Save statistics gathered by evolve_plan_baselines, if it ran:
--
estimated_startup_cost = EXCLUDED.estimated_startup_cost,
estimated_total_cost = EXCLUDED.estimated_total_cost,
planning_time_ms = EXCLUDED.planning_time_ms,
execution_time_ms = EXCLUDED.execution_time_ms,
total_time_benefit_ms = EXCLUDED.total_time_benefit_ms,
execution_time_benefit_ms = EXCLUDED.execution_time_benefit_ms;
```
1. Reload the managed plans into shared memory and remove the temporary plans table.
```
SELECT apg_plan_mgmt.reload(); -- refresh shared memory
DROP TABLE plans_copy;
```
# Parameter reference for Aurora PostgreSQL query plan management
You can set your preferences for the `apg_plan_mgmt` extension by using the parameters listed in this section. These are available in the custom DB cluster parameter and the DB parameter group associated with your Aurora PostgreSQL DB cluster. These parameters control the behavior of the query plan management feature and how it affects the optimizer. For information about setting up query plan management, see [Turning on Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.overview.md#AuroraPostgreSQL.Optimize.Enable). Changing the parameters following has no effect if the `apg_plan_mgmt` extension isn't set up as detailed in that section. For information about modifying parameters, see [Modifying parameters in a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md) and [DB parameter groups for Amazon Aurora DB instances](USER_WorkingWithDBInstanceParamGroups.md).
**Topics**
+ [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines)
+ [apg\$1plan\$1mgmt.plan\$1capture\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.plan_capture_threshold)
+ [apg\$1plan\$1mgmt.explain\$1hashes](#AuroraPostgreSQL.Optimize.Parameters.explain_hashes)
+ [apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result](#AuroraPostgreSQL.Optimize.Parameters.log_plan_enforcement_result)
+ [apg\$1plan\$1mgmt.max\$1databases](#AuroraPostgreSQL.Optimize.Parameters.max_databases)
+ [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans)
+ [apg\$1plan\$1mgmt.plan\$1hash\$1version](#AuroraPostgreSQL.Optimize.Parameters.plan_hash_version)
+ [apg\$1plan\$1mgmt.plan\$1retention\$1period](#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period)
+ [apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold](#AuroraPostgreSQL.Optimize.Parameters.unapproved_plan_execution_threshold)
+ [apg\$1plan\$1mgmt.use\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Parameters.use_plan_baselines)
+ [auto\$1explain.hashes](#AuroraPostgreSQL.Optimize.Parameters.auto_explain.hashes)
## apg\$1plan\$1mgmt.capture\$1plan\$1baselines
Captures query execution plans generated by the optimizer for each SQL statement and stores them in the `dba_plans` view. By default, the maximum number of plans that can be stored is 10,000 as specified by the `apg_plan_mgmt.max_plans` parameter. For reference information, see [apg\$1plan\$1mgmt.max\$1plans](#AuroraPostgreSQL.Optimize.Parameters.max_plans).
You can set this parameter in the custom DB cluster parameter group or in the custom DB parameter group. Changing the value of this parameter doesn't require a reboot.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
For more information, see [Capturing Aurora PostgreSQL execution plans](AuroraPostgreSQL.Optimize.CapturePlans.md).
## apg\$1plan\$1mgmt.plan\$1capture\$1threshold
Specifies a threshold so that if the total cost of the query execution plan is below the threshold, the plan won’t be captured in the `apg_plan_mgmt.dba_plans` view.
Changing the value of this parameter doesn't require a reboot.
| Default | Allowed values | Description |
| --- | --- | --- |
| 0 | 0 - 1.79769e\$1308 | Sets the threshold of the `apg_plan_mgmt` query plan total execution cost for capturing plans. |
For more information, see [Examining Aurora PostgreSQL query plans in the dba\$1plans view](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.explain\$1hashes
Specifies if the `EXPLAIN [ANALYZE]` shows `sql_hash` and `plan_hash` at the end of its output. Changing the value of this parameter doesn't require a reboot.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.log\$1plan\$1enforcement\$1result
Specifies if the results has to be recorded to see if the QPM managed plans are used properly. When a stored generic plan is used, there will be no records written in the log files. Changing the value of this parameter doesn't require a reboot.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.max\$1databases
Specifies the maximum number of databases on your Aurora PostgreSQL DB cluster's Writer instance that can use query plan management. By default, up to 10 databases can use query plan management. If you have more than 10 databases on the instance, you can change the value of this setting. To find out how many databases are on a given instance, connect to the instance using `psql`. Then, use the psql metacommand, `\l`, to list the databases.
Changing the value of this parameter requires that you reboot the instance for the setting to take effect.
| Default | Allowed values | Description |
| --- | --- | --- |
| 10 | 10-2147483647 | Maximum number of databases that can use query plan management on the instance. |
You can set this parameter in the custom DB cluster parameter group or in the custom DB parameter group.
## apg\$1plan\$1mgmt.max\$1plans
Sets the maximum number of SQL statements that the query plan manager can maintain in the `apg_plan_mgmt.dba_plans` view. We recommend setting this parameter to `10000` or higher for all Aurora PostgreSQL versions.
You can set this parameter in the custom DB cluster parameter group or in the custom DB parameter group. Changing the value of this parameter requires that you reboot the instance for the setting to take effect.
| Default | Allowed values | Description |
| --- | --- | --- |
| 10000 | 10-2147483647 | Maximum number of plans that can be stored in the `apg_plan_mgmt.dba_plans` view. Default for Aurora PostgreSQL version 10 and older versions is 1000. |
For more information, see [Examining Aurora PostgreSQL query plans in the dba\$1plans view](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.plan\$1hash\$1version
Specifies the use cases that the plan\$1hash calculation is designed to cover. A higher version of `apg_plan_mgmt.plan_hash_version` covers all the functionality of the lower version. For example, version 3 covers the use cases supported by version 2.
Changing the value of this parameter must be followed by a call to `apg_plan_mgmt.validate_plans('update_plan_hash')`. It updates the plan\$1hash values in each database with apg\$1plan\$1mgmt installed and entries in the plans table. For more information, see [Validating plans](AuroraPostgreSQL.Optimize.Deleting.md#AuroraPostgreSQL.Optimize.Maintenance.ValidatingPlans)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
## apg\$1plan\$1mgmt.plan\$1retention\$1period
Specifies the number of days to keep plans in the `apg_plan_mgmt.dba_plans` view, after which they're automatically deleted. By default, a plan is deleted when 32 days have elapsed since the plan was last used (the `last_used` column in the `apg_plan_mgmt.dba_plans` view). You can change this setting to any number, 1 and over.
Changing the value of this parameter requires that you reboot the instance for the setting to take effect.
| Default | Allowed values | Description |
| --- | --- | --- |
| 32 | 1-2147483647 | Maximum number of days since a plan was last used before it's deleted. |
For more information, see [Examining Aurora PostgreSQL query plans in the dba\$1plans view](AuroraPostgreSQL.Optimize.ViewPlans.md).
## apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold
Specifies a cost threshold below which an Unapproved plan can be used by the optimizer. By default the threshold is 0, so the optimizer doesn't run Unapproved plans. Setting this parameter to a trivially low cost threshold such as 100 avoids plan enforcement overhead on trivial plans. You can also set this parameter to an extremely large value like 10000000 using the reactive style of plan management. This allows the optimizer to use all chosen plans with no plan enforcement overhead. But, when a bad plan is found, you can manually mark it as "rejected" so that it is not used next time.
The value of this parameter represents a cost estimate for running a given plan. If an Unapproved plan is below that estimated cost, the optimizer uses it for the SQL statement. You can see captured plans and their status (Approved, Unapproved) in the `dba_plans` view. To learn more, see [Examining Aurora PostgreSQL query plans in the dba\$1plans view](AuroraPostgreSQL.Optimize.ViewPlans.md).
Changing the value of this parameter doesn't require a reboot.
| Default | Allowed values | Description |
| --- | --- | --- |
| 0 | 0-2147483647 | Estimated plan cost below which an Unapproved plan is used. |
For more information, see [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md).
## apg\$1plan\$1mgmt.use\$1plan\$1baselines
Specifies that the optimizer should use one of the Approved plans captured and stored in the `apg_plan_mgmt.dba_plans` view. By default, this parameter is off (false), causing the optimizer to use the minimum-cost plan that it generates without any further assessment. Turning this parameter on (setting it to true) forces the optimizer to choose a query execution plan for the statement from its plan baseline. For more information, see [Using Aurora PostgreSQL managed plans](AuroraPostgreSQL.Optimize.UsePlans.md). To find an image detailing this process, see [How the optimizer chooses which plan to run](AuroraPostgreSQL.Optimize.UsePlans.md#AuroraPostgreSQL.Optimize.UsePlans.ChoosePlans).
You can set this parameter in the custom DB cluster parameter group or in the custom DB parameter group. Changing the value of this parameter doesn't require a reboot.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
You can evaluate response times of different captured plans and change plan status, as needed. For more information, see [Improving Aurora PostgreSQL query plans](AuroraPostgreSQL.Optimize.Maintenance.md).
## auto\$1explain.hashes
Specifies if the auto\$1explain output shows sql\$1hash and plan\$1hash. Changing the value of this parameter doesn't require a reboot.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Parameters.html)
# Function reference for Aurora PostgreSQL query plan management
The `apg_plan_mgmt` extension provides the following functions.
**Topics**
+ [apg\$1plan\$1mgmt.copy\$1outline](#AuroraPostgreSQL.Optimize.Functions.copy_outline)
+ [apg\$1plan\$1mgmt.delete\$1plan](#AuroraPostgreSQL.Optimize.Functions.delete_plan)
+ [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines)
+ [apg\$1plan\$1mgmt.get\$1explain\$1plan](#AuroraPostgreSQL.Optimize.Functions.get_explain_plan)
+ [apg\$1plan\$1mgmt.plan\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.plan_last_used)
+ [apg\$1plan\$1mgmt.reload](#AuroraPostgreSQL.Optimize.Functions.reload)
+ [apg\$1plan\$1mgmt.set\$1plan\$1enabled](#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled)
+ [apg\$1plan\$1mgmt.set\$1plan\$1status](#AuroraPostgreSQL.Optimize.Functions.set_plan_status)
+ [apg\$1plan\$1mgmt.update\$1plans\$1last\$1used](#AuroraPostgreSQL.Optimize.Functions.update_plans_last_used)
+ [apg\$1plan\$1mgmt.validate\$1plans](#AuroraPostgreSQL.Optimize.Functions.validate_plans)
## apg\$1plan\$1mgmt.copy\$1outline
Copy a given SQL plan hash and plan outline to a target SQL plan hash and outline, thereby overwriting the target's plan hash and outline. This function is available in `apg_plan_mgmt` 2.3 and higher releases.
**Syntax**
```
apg_plan_mgmt.copy_outline(
source_sql_hash,
source_plan_hash,
target_sql_hash,
target_plan_hash,
force_update_target_plan_hash
)
```
**Return value**
Returns 0 when the copy is successful. Raises exceptions for invalid inputs.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| source\$1sql\$1hash | The sql\$1hash ID associated with the plan\$1hash to copy to the target query. |
| source\$1plan\$1hash | The plan\$1hash ID to copy to the target query. |
| target\$1sql\$1hash | The sql\$1hash ID of the query to update with the source plan hash and outline. |
| target\$1plan\$1hash | The plan\$1hash ID of the query to update with the source plan hash and outline. |
| force\$1update\$1target\$1plan\$1hash | (Optional) The target\$1plan\$1hash ID of the query is updated even if the source plan isn't reproducible for the target\$1sql\$1hash. When set to true, the function can be used to copy plans across schemas where relation names and columns are consistent. |
**Usage notes**
This function allows you to copy a plan hash and plan outline that uses hints to other, similar statements, and thus saves you from needing to use in-line hint statements at every occurrence in the target statements. If the updated target query results in an invalid plan, this function raises an error and rolls back the attempted update.
## apg\$1plan\$1mgmt.delete\$1plan
Delete a managed plan.
**Syntax**
```
apg_plan_mgmt.delete_plan(
sql_hash,
plan_hash
)
```
**Return value**
Returns 0 if the delete was successful or -1 if the delete failed.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. |
## apg\$1plan\$1mgmt.evolve\$1plan\$1baselines
Verifies whether an already approved plan is faster or whether a plan identified by the query optimizer as a minimum cost plan is faster.
**Syntax**
```
apg_plan_mgmt.evolve_plan_baselines(
sql_hash,
plan_hash,
min_speedup_factor,
action
)
```
**Return value**
The number of plans that were not faster than the best approved plan.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. Use NULL to mean all plans that have the same sql\$1hash ID value. |
| min\$1speedup\$1factor | The *minimum speedup factor* can be the number of times faster that a plan must be than the best of the already approved plans to approve it. Alternatively, this factor can be the number of times slower that a plan must be to reject or disable it. This is a positive float value. |
| action | The action the function is to perform. Valid values include the following. Case does not matter. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
** Usage notes**
Set specified plans to approved, rejected, or disabled based on whether the planning plus execution time is faster than the best approved plan by a factor that you can set. The action parameter might be set to `'approve'` or `'reject'` to automatically approve or reject a plan that meets the performance criteria. Alternatively, it might be set to '' (empty string) to do the performance experiment and produce a report, but take no action.
You can avoid pointlessly rerunning of the `apg_plan_mgmt.evolve_plan_baselines` function for a plan on which it was recently run. To do so, restrict the plans to just the recently created unapproved plans. Alternatively, you can avoid running the `apg_plan_mgmt.evolve_plan_baselines` function on any approved plan that has a recent `last_verified` timestamp.
Conduct a performance experiment to compare the planning plus execution time of each plan relative to the other plans in the baseline. In some cases, there is only one plan for a statement and the plan is approved. In such a case, compare the planning plus execution time of the plan to the planning plus execution time of using no plan.
The incremental benefit (or disadvantage) of each plan is recorded in the `apg_plan_mgmt.dba_plans` view in the `total_time_benefit_ms` column. When this value is positive, there is a measurable performance advantage to including this plan in the baseline.
In addition to collecting the planning and execution time of each candidate plan, the `last_verified` column of the `apg_plan_mgmt.dba_plans` view is updated with the `current_timestamp`. The `last_verified` timestamp might be used to avoid running this function again on a plan that recently had its performance verified.
## apg\$1plan\$1mgmt.get\$1explain\$1plan
Generates the text of an `EXPLAIN` statement for the specified SQL statement.
**Syntax**
```
apg_plan_mgmt.get_explain_plan(
sql_hash,
plan_hash,
[explainOptionList]
)
```
**Return value**
Returns runtime statistics for the specified SQL statements. Use without `explainOptionList` to return a simple `EXPLAIN` plan.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. |
| explainOptionList | A comma-separated list of explain options. Valid values include `'analyze'`, `'verbose'`, `'buffers'`, `'hashes'`, and `'format json'`. If the `explainOptionList` is NULL or an empty string (''), this function generates an `EXPLAIN` statement, without any statistics. |
**Usage notes**
For the `explainOptionList`, you can use any of the same options that you would use with an `EXPLAIN` statement. The Aurora PostgreSQL optimizer concatenates the list of options that you provide to the `EXPLAIN` statement.
## apg\$1plan\$1mgmt.plan\$1last\$1used
Returns the `last_used` date of the specified plan from shared memory.
**Note**
The value in shared memory is always current on the primary DB instance in the DB cluster. The value is only periodically flushed to the `last_used` column of the `apg_plan_mgmt.dba_plans` view.
**Syntax**
```
apg_plan_mgmt.plan_last_used(
sql_hash,
plan_hash
)
```
**Return value**
Returns the `last_used` date.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. |
## apg\$1plan\$1mgmt.reload
Reload plans into shared memory from the `apg_plan_mgmt.dba_plans` view.
**Syntax**
```
apg_plan_mgmt.reload()
```
**Return value**
None.
**Parameters**
None.
** Usage notes**
Call `reload` for the following situations:
+ Use it to refresh the shared memory of a read-only replica immediately, rather than wait for new plans to propagate to the replica.
+ Use it after importing managed plans.
## apg\$1plan\$1mgmt.set\$1plan\$1enabled
Enable or disable a managed plan.
**Syntax**
```
apg_plan_mgmt.set_plan_enabled(
sql_hash,
plan_hash,
[true | false]
)
```
**Return value**
Returns 0 if the setting was successful or -1 if the setting failed.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. |
| enabled | Boolean value of true or false: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) |
## apg\$1plan\$1mgmt.set\$1plan\$1status
Set a managed plan's status to `Approved`, `Unapproved`, `Rejected`, or `Preferred`.
**Syntax**
```
apg_plan_mgmt.set_plan_status(
sql_hash,
plan_hash,
status
)
```
**Return value**
Returns 0 if the setting was successful or -1 if the setting failed.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. |
| status | A string with one of the following values: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) The case you use does not matter, however the status value is set to initial uppercase in the `apg_plan_mgmt.dba_plans` view. For more information about these values, see `status` in [Reference for the apg\$1plan\$1mgmt.dba\$1plans view for Aurora PostgreSQL-Compatible Edition](AuroraPostgreSQL.Optimize.dba_plans_view_Reference.md). |
## apg\$1plan\$1mgmt.update\$1plans\$1last\$1used
Immediately updates the plans table with the `last_used` date stored in shared memory.
**Syntax**
```
apg_plan_mgmt.update_plans_last_used()
```
**Return value**
None.
**Parameters**
None.
** Usage notes**
Call `update_plans_last_used` to make sure queries against the `dba_plans.last_used` column use the most current information. If the `last_used` date isn't updated immediately, a background process updates the plans table with the `last_used` date once every hour (by default).
For example, if a statement with a certain `sql_hash` begins to run slowly, you can determine which plans for that statement were executed since the performance regression began. To do that, first flush the data in shared memory to disk so that the `last_used` dates are current, and then query for all plans of the `sql_hash` of the statement with the performance regression. In the query, make sure the `last_used` date is greater than or equal to the date on which the performance regression began. The query identifies the plan or set of plans that might be responsible for the performance regression. You can use `apg_plan_mgmt.get_explain_plan` with `explainOptionList` set to `verbose, hashes`. You can also use `apg_plan_mgmt.evolve_plan_baselines` to analyze the plan and any alternative plans that might perform better.
The `update_plans_last_used` function has an effect only on the primary DB instance of the DB cluster.
## apg\$1plan\$1mgmt.validate\$1plans
Validate that the optimizer can still recreate plans. The optimizer validates `Approved`, `Unapproved`, and `Preferred` plans, whether the plan is enabled or disabled. `Rejected` plans are not validated. Optionally, you can use the `apg_plan_mgmt.validate_plans` function to delete or disable invalid plans.
**Syntax**
```
apg_plan_mgmt.validate_plans(
sql_hash,
plan_hash,
action)
apg_plan_mgmt.validate_plans(
action)
```
**Return value**
The number of invalid plans.
**Parameters**
****
| Parameter | Description |
| --- | --- |
| sql\$1hash | The sql\$1hash ID of the plan's managed SQL statement. |
| plan\$1hash | The managed plan's plan\$1hash ID. Use NULL to mean all plans for the same sql\$1hash ID value. |
| action | The action the function is to perform for invalid plans. Valid string values include the following. Case does not matter. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Functions.html) Any other value is treated like the empty string. |
**Usage notes**
Use the form `validate_plans(action)` to validate all the managed plans for all the managed statements in the entire `apg_plan_mgmt.dba_plans` view.
Use the form `validate_plans(sql_hash, plan_hash, action)` to validate a managed plan specified with `plan_hash`, for a managed statement specified with `sql_hash`.
Use the form `validate_plans(sql_hash, NULL, action)` to validate all the managed plans for the managed statement specified with `sql_hash`.
# Reference for the apg\$1plan\$1mgmt.dba\$1plans view for Aurora PostgreSQL-Compatible Edition
The columns of plan information in the `apg_plan_mgmt.dba_plans` view include the following.
| dba\$1plans column | Description |
| --- | --- |
| cardinality\$1error | A measure of the error between the estimated cardinality versus the actual cardinality. *Cardinality* is the number of table rows that the plan is to process. If the cardinality error is large, then it increases the likelihood that the plan isn't optimal. This column is populated by the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
| compatibility\$1level | This parameter shows when a query plan was last validated. In Aurora PostgreSQL versions 12.19, 13.15, 14.12, 15.7, 16.3, and later, it displays the Aurora version number. For earlier versions, it displays a feature specific version number. Keep this parameter value at its default setting. Aurora PostgreSQL automatically sets and updates this value. |
| created\$1by | The authenticated user (session\$1user) who created the plan. |
| enabled | An indicator of whether the plan is enabled or disabled. All plans are enabled by default. You can disable plans to prevent them from being used by the optimizer. To modify this value, use the [apg\$1plan\$1mgmt.set\$1plan\$1enabled](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.set_plan_enabled) function. |
| environment\$1variables | The PostgreSQL Grand Unified Configuration (GUC) parameters and values that the optimizer has overridden at the time the plan was captured. |
| estimated\$1startup\$1cost | The estimated optimizer setup cost before the optimizer delivers rows of a table. |
| estimated\$1total\$1cost | The estimated optimizer cost to deliver the final table row. |
| execution\$1time\$1benefit\$1ms | The execution time benefit in milliseconds of enabling the plan. This column is populated by the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
| execution\$1time\$1ms | The estimated time in milliseconds that the plan would run. This column is populated by the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
| has\$1side\$1effects | A value that indicates that the SQL statement is a data manipulation language (DML) statement or a SELECT statement that contains a VOLATILE function. |
| last\$1used | This value is updated to the current date whenever the plan is either executed or when the plan is the query optimizer's minimum-cost plan. This value is stored in shared memory and periodically flushed to disk. To get the most up-to-date value, read the date from shared memory by calling the function apg\$1plan\$1mgmt.plan\$1last\$1used(sql\$1hash, plan\$1hash) instead of reading the last\$1used value. For additional information, see the [apg\$1plan\$1mgmt.plan\$1retention\$1period](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.plan_retention_period) parameter. |
| last\$1validated | The most recent date and time when it was verified that the plan could be recreated by either the [apg\$1plan\$1mgmt.validate\$1plans](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.validate_plans) function or the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
| last\$1verified | The most recent date and time when a plan was verified to be the best-performing plan for the specified parameters by the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
| origin | How the plan was captured with the [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines) parameter. Valid values include the following: `M` – The plan was captured with manual plan capture. `A` – The plan was captured with automatic plan capture. |
| param\$1list | The parameter values that were passed to the statement if this is a prepared statement. |
| plan\$1created | The date and time the plan that was created. |
| plan\$1hash | The plan identifier. The combination of plan\$1hash and sql\$1hash uniquely identifies a specific plan. |
| plan\$1outline | A representation of the plan that is used to recreate the actual execution plan, and that is database-independent. Operators in the tree correspond to operators that appear in the EXPLAIN output. |
| planning\$1time\$1ms | The actual time to run the planner, in milliseconds. This column is populated by the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
| queryId | A statement hash, as calculated by the pg\$1stat\$1statements extension. This isn't a stable or database-independent identifier because it depends on object identifiers (OIDs). The value will be 0 if compute\$1query\$1id is off when capturing the query plan. |
| sql\$1hash | A hash value of the SQL statement text, normalized with literals removed. |
| sql\$1text | The full text of the SQL statement. |
| status | A plan's status, which determines how the optimizer uses a plan. Valid values include the following. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.dba_plans_view_Reference.html) |
| stmt\$1name | The name of the SQL statement within a PREPARE statement. This value is an empty string for an unnamed prepared statement. This value is NULL for a nonprepared statement. |
| total\$1time\$1benefit\$1ms | The total time benefit in milliseconds of enabling this plan. This value considers both planning time and execution time. If this value is negative, there is a disadvantage to enabling this plan. This column is populated by the [apg\$1plan\$1mgmt.evolve\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Functions.md#AuroraPostgreSQL.Optimize.Functions.evolve_plan_baselines) function. |
# Advanced features in Query Plan Management
Following you can find information about the advanced Aurora PostgreSQL Query Plan Management (QPM) features:
**Topics**
+ [Capturing Aurora PostgreSQL execution plans in Replicas](AuroraPostgreSQL.QPM.Plancapturereplicas.md)
+ [Supporting table partition](AuroraPostgreSQL.QPM.Partitiontable.md)
# Capturing Aurora PostgreSQL execution plans in Replicas
QPM (Query Plan Management) allows you to capture the query plans generated by Aurora Replicas and stores them on the primary DB instance of the Aurora DB cluster. You can collect the query plans from all the Aurora Replicas, and maintain a set of optimal plans in a central persistent table on the primary instance. You can then apply these plans on other Replicas when needed. This helps you to maintain the stability of execution plans and improve performance of the queries across the DB clusters and engine versions.
**Topics**
+ [Prerequisites](#AuroraPostgreSQL.QPM.Plancapturereplicas.Prereq)
+ [Managing plan capture for Aurora Replicas](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing)
+ [Troubleshooting](#AuroraPostgreSQL.QPM.Plancapturereplicas.Troubleshooting)
## Prerequisites
**Turn on `capture_plan_baselines parameter` in Aurora Replica** - Set `capture_plan_baselines` parameter to automatic or manual to capture plans in Aurora Replicas. For more information, see [apg\$1plan\$1mgmt.capture\$1plan\$1baselines](AuroraPostgreSQL.Optimize.Parameters.md#AuroraPostgreSQL.Optimize.Parameters.capture_plan_baselines).
**Install postgres\$1fdw extension** - You must install `postgres_fdw` foreign data wrapper extension to capture plans in Aurora Replicas. Run the following command in each database, to install the extension.
```
postgres=> CREATE EXTENSION IF NOT EXISTS postgres_fdw;
```
## Managing plan capture for Aurora Replicas
**Turn on plan capture for Aurora Replicas**
You must have `rds_superuser` privileges to create or remove Plan Capture in Aurora Replicas. For more information on user roles and permissions, see [Understanding PostgreSQL roles and permissions](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Roles.html).
To capture plans, call the function apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture in the writer DB instance, as shown in the following:
```
postgres=> CALL apg_plan_mgmt.create_replica_plan_capture('endpoint', 'password');
```
+ endpoint - Aurora Global Database writer endpoint or cluster\$1endpoint provides failover support for Plan Capture in Aurora Replicas.
For more information on the Aurora Global Database writer endpoint, see [Viewing the endpoints of an Amazon Aurora global database](aurora-global-database-connecting.md#viewing-endpoints).
For more information about cluster endpoints, see [Cluster endpoints for Amazon Aurora](Aurora.Endpoints.Cluster.md).
+ password - We recommend you to follow the below guidelines while creating the password to enhance the security:
+ It must contain at least 8 characters.
+ It must contain at least one uppercase, one lowercase letter, and one number.
+ It must have at least one special character (`?`, `!`, `#`, `<`, `>`, `*`, and so on).
**Note**
If you change the endpoint, password, or port number, you must run `apg_plan_mgmt.create_replica_plan_capture()` again with the endpoint and password to re-initialize the plan capture. If not, capturing plans from Aurora Replicas will fail.
**Turn off plan capture for Aurora Replicas**
You can turn off `capture_plan_baselines` parameter in Aurora Replica by setting its value to `off` in the Parameter group.
**Remove plan capture for Aurora Replicas**
You can completely remove Plan Capture in Aurora Replicas but make sure before you do. To remove plan capture, call `apg_plan_mgmt.remove_replica_plan_capture` as shown:
```
postgres=> CALL apg_plan_mgmt.remove_replica_plan_capture();
```
You must call apg\$1plan\$1mgmt.create\$1replica\$1plan\$1capture() again to turn on plan capture in Aurora Replicas with the endpoint and password.
## Troubleshooting
Following, you can find troubleshooting ideas and workarounds if the plan is not captured in Aurora Replicas as expected.
+ **Parameter settings** - Check if the `capture_plan_baselines` parameter is set to proper value to turn on plan capture.
+ **`postgres_fdw` extension is installed** - Use the following query to check if `postgres_fdw` is installed.
```
postgres=> SELECT * FROM pg_extension WHERE extname = 'postgres_fdw'
```
+ **create\$1replica\$1plan\$1capture() is called** - Use the following command to check if the user mapping exits. Otherwise, call `create_replica_plan_capture()` to initialize the feature.
```
postgres=> SELECT * FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **Endpoint and port number** - Check if the endpoint and port number are appropriate. There won't be any error message displayed if these values are incorrect.
Use the following command to verify if the endpoint used in the create() and to check which database it resides in:
```
postgres=> SELECT srvoptions FROM pg_foreign_server WHERE srvname = 'apg_plan_mgmt_writer_foreign_server';
```
+ **reload()** - You must call apg\$1plan\$1mgmt.reload() after calling apg\$1plan\$1mgmt.delete\$1plan() in Aurora Replicas to make the delete function effective. This ensures that the change has been successfully implemented.
+ **Password** - You must enter password in create\$1replica\$1plan\$1capture() as per the guidelines mentioned. Otherwise, you will receive an error message. For more information,see [Managing plan capture for Aurora Replicas](#AuroraPostgreSQL.QPM.Plancapturereplicas.managing). Use another password that aligns with the requirements.
+ **Cross-Region connection** - Plan capture in Aurora Replicas is also supported in Aurora global database, where writer instance and Aurora Replicas can be in different regions. Ensure that you use the Aurora Global Database writer endpoint to maintain connectivity after failover or switchover events. For more information on the Aurora Global Database endpoints, see [Viewing the endpoints of an Amazon Aurora Global Database](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#viewing-endpoints). The writer instance and cross-Region Replica must be able to communicate, using VPC Peering. For more information, see [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html). If a cross-Region failover happens, you must reconfigure the endpoint to new primary DB cluster endpoint.
**Note**
When using a cluster endpoint instead of an Aurora Global Database writer endpoint, you'll need to update the cluster endpoint after performing either a global failover or switchover operation.
# Supporting table partition
Aurora PostgreSQL Query Plan Management (QPM) supports declarative table partitioning in the following versions:
+ 15.3 and higher 15 versions
+ 14.8 and higher 14 versions
+ 13.11 and higher 13 versions
For more information, see [Table Partitioning](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Topics**
+ [Setting up table partition](#AuroraPostgreSQL.QPM.Partitiontable.setup)
+ [Capturing plans for table partition](#AuroraPostgreSQL.QPM.Partitiontable.capture)
+ [Enforcing a table partition plan](#AuroraPostgreSQL.QPM.Partitiontable.enforcement)
+ [Naming Convention](#AuroraPostgreSQL.QPM.Partitiontable.naming.convention)
## Setting up table partition
To set up table partition in Aurora PostgreSQL QPM, do as follows:
1. Set `apg_plan_mgmt.plan_hash_version` to 3 or more in the DB cluster parameter group.
1. Navigate to a database that uses Query Plan Management and has entries in `apg_plan_mgmt.dba_plans` view.
1. Call `apg_plan_mgmt.validate_plans('update_plan_hash')` to update the `plan_hash` value in the plans table.
1. Repeat steps 2-3 for all databases with Query Plan Management enabled that have entries in `apg_plan_mgmt.dba_plans` view.
For more information on these parameters, see [Parameter reference for Aurora PostgreSQL query plan management](AuroraPostgreSQL.Optimize.Parameters.md).
## Capturing plans for table partition
In QPM, different plans are distinguished by their `plan_hash` value. To understand how the `plan_hash` changes, you must first understand similar kind of plans.
The combination of access methods, digit-stripped index names and digit-stripped partition names, accumulated at the Append node level must be constant for plans to be considered the same. The specific partitions accessed in the plans are not significant. In the following example, a table `tbl_a` is created with 4 partitions.
```
postgres=>create table tbl_a(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table tbl_a1 partition of tbl_a for values from (0) to (1000);
CREATE TABLE
postgres=>create table tbl_a2 partition of tbl_a for values from (1001) to (2000);
CREATE TABLE
postgres=>create table tbl_a3 partition of tbl_a for values from (2001) to (3000);
CREATE TABLE
postgres=>create table tbl_a4 partition of tbl_a for values from (3001) to (4000);
CREATE TABLE
postgres=>create index t_i on tbl_a using btree (i);
CREATE INDEX
postgres=>create index t_j on tbl_a using btree (j);
CREATE INDEX
postgres=>create index t_k on tbl_a using btree (k);
CREATE INDEX
```
The following plans are considered the same because a single scan method is being used to scan `tbl_a` irrespective of the number of partitions that the query looks up.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 999 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Seq Scan on tbl_a1 tbl_a
Filter: ((i >= 990) AND (i <= 999) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(3 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(8 rows)
```
The following 3 plans are also considered the same because at the parent level, the access methods, digit-stripped index names and digit-stripped partition names are `SeqScan tbl_a`, `IndexScan (i_idx) tbl_a`.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_i_idx on tbl_a2 tbl_a_2
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(7 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a3 tbl_a_3
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(11 rows)
```
Irrespective of different order and number of occurrences in child partitions, the access methods, digit-stripped index names and digit-stripped partition names are constant at the parent level for each of the above plans.
However, the plans would be considered different if any of the following conditions are met:
+ Any additional access methods are used in the plan.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 1134525070
(11 rows)
```
+ Any of the access methods in the plan are not used anymore.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -694232056
(6 rows)
```
+ The index associated with an index method is changed.
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Seq Scan on tbl_a1 tbl_a_1
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a2_j_idx on tbl_a2 tbl_a_2
Index Cond: (j < 9910)
Filter: ((i >= 990) AND (i <= 1100) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993343726
(7 rows)
```
## Enforcing a table partition plan
Approved plans for partitioned tables are enforced with positional correspondence. The plans are not specific to the partitions, and can be enforced on partitions other than the plans referenced in the original query. Plans also have the capability of being enforced for queries accessing a different number of partitions than the original approved outline.
For example, if the approved outline is for the following plan:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
SQL Hash: 1553185667, Plan Hash: -993736942
(10 rows)
```
Then, this plan can be enforced on SQL queries referencing 2, 4, or more partitions as well. The possible plans that could arise from these scenarios for 2 and 4 partition access are:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(8 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a4 tbl_a_4
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(12 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 3100 and j < 9910 and k > 50;
QUERY PLAN
----------------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 3100) AND (j < 9910) AND (k > 50))
-> Index Scan using tbl_a3_i_idx on tbl_a3 tbl_a_3
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
-> Index Scan using tbl_a4_i_idx on tbl_a4 tbl_a_4
Index Cond: ((i >= 990) AND (i <= 3100))
Filter: ((j < 9910) AND (k > 50))
Note: An Approved plan was used instead of the minimum cost plan.
SQL Hash: 1553185667, Plan Hash: -993736942, Minimum Cost Plan Hash: -1873216041
(14 rows)
```
Consider another approved plan with different access methods for each partition:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 2100 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 2100) AND (j < 9910) AND (k > 50))
-> Bitmap Heap Scan on tbl_a3 tbl_a_3
Recheck Cond: ((i >= 990) AND (i <= 2100))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a3_i_idx
Index Cond: ((i >= 990) AND (i <= 2100))
SQL Hash: 1553185667, Plan Hash: 2032136998
(12 rows)
```
In this case, any plan that reads from two partitions would fail to be enforced. Unless all of the (access method, index name) combinations from the approved plan are usable, the plan cannot be enforced. For example, the following plans have different plan hashes and the approved plan can't be enforced in these cases:
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
-------------------------------------------------------------------------
Append
-> Bitmap Heap Scan on tbl_a1 tbl_a_1
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a1_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
-> Bitmap Heap Scan on tbl_a2 tbl_a_2
Recheck Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Bitmap Index Scan on tbl_a2_i_idx
Index Cond: ((i >= 990) AND (i <= 1900))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -568647260
(13 rows)
```
```
postgres=>explain (hashes true, costs false) select j, k from tbl_a where i between 990 and 1900 and j < 9910 and k > 50;
QUERY PLAN
--------------------------------------------------------------------------
Append
-> Index Scan using tbl_a1_i_idx on tbl_a1 tbl_a_1
Index Cond: ((i >= 990) AND (i <= 1900))
Filter: ((j < 9910) AND (k > 50))
-> Seq Scan on tbl_a2 tbl_a_2
Filter: ((i >= 990) AND (i <= 1900) AND (j < 9910) AND (k > 50))
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: 1553185667, Plan Hash: -496793743
(8 rows)
```
## Naming Convention
For QPM to enforce a plan with declarative partitioned tables, you must follow specific naming rules for parent tables, table partitions, and indexes:
+ **Parent table names** – These names must differ by alphabets or special characters, and not by just digits. For example, tA, tB, and tC are acceptable names for separate parent tables while t1, t2, and t3 are not.
+ **Individual partition table names** – Partitions of the same parent should differ from one another by digits only. For example, acceptable partition names of tA could be tA1, tA2 or t1A, t2A or even multiple digits.
Any other differences (letters, special characters) will not guarantee plan enforcement.
+ **Index names** – In partition table hierarchy, make sure that all indexes have unique names. This means that the non-numeric parts of the names must be different. For example, if you have a partitioned table named `tA` with an index named `tA_col1_idx1`, you can't have another index named `tA_col1_idx2`. However, you can have an index called `tA_a_col1_idx2` because the non-numeric part of the name is unique. This rule applies to indexes created on both the parent table and individual partition tables.
Failure to adhere to the above naming conventions may result in failure of approved plans enforcement. The following example illustrates such a failed enforcement:
```
postgres=>create table t1(i int, j int, k int, l int, m int) partition by range(i);
CREATE TABLE
postgres=>create table t1a partition of t1 for values from (0) to (1000);
CREATE TABLE
postgres=>create table t1b partition of t1 for values from (1001) to (2000);
CREATE TABLE
postgres=>SET apg_plan_mgmt.capture_plan_baselines TO 'manual';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 0;
QUERY PLAN
--------------------------------------------------------------------------
Aggregate
-> Append
-> Seq Scan on t1a t1_1
Filter: (i > 0)
-> Seq Scan on t1b t1_2
Filter: (i > 0)
SQL Hash: -1720232281, Plan Hash: -1010664377
(7 rows)
```
```
postgres=>SET apg_plan_mgmt.use_plan_baselines TO 'on';
SET
postgres=>explain (hashes true, costs false) select count(*) from t1 where i > 1000;
QUERY PLAN
-------------------------------------------------------------------------
Aggregate
-> Seq Scan on t1b t1
Filter: (i > 1000)
Note: This is not an Approved plan. No usable Approved plan was found.
SQL Hash: -1720232281, Plan Hash: 335531806
(5 rows)
```
Even though the two plans might appear identical, their `Plan Hash` values are different due to the names of the child tables. The table names vary by alpha characters instead of just digits leading to an enforcement failure.
# Working with extensions and foreign data wrappers
To extend the functionality to your Aurora PostgreSQL-Compatible Edition DB cluster, you can install and use various PostgreSQL *extensions*. For example, if your use case calls for intensive data entry across very large tables, you can install the `[pg\$1partman](https://pgxn.org/dist/pg_partman/doc/pg_partman.html)` extension to partition your data and thus spread the workload.
**Note**
As of Aurora PostgreSQL 14.5, Aurora PostgreSQL supports Trusted Language Extensions for PostgreSQL. This feature is implemented as the extension `pg_tle`, which you can add to your Aurora PostgreSQL. By using this extension, developers can create their own PostgreSQL extensions in a safe environment that simplifies the setup and configuration requirements, as well as much of the preliminary testing for new extensions. For more information, see [Working with Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension.md).
In some cases, rather than installing an extension, you might add a specific *module* to the list of `shared_preload_libraries` in your Aurora PostgreSQL DB cluster's custom DB cluster parameter group. Typically, the default DB cluster parameter group loads only the `pg_stat_statements`, but several other modules are available to add to the list. For example, you can add scheduling capability by adding the `pg_cron` module, as detailed in [Scheduling maintenance with the PostgreSQL pg\$1cron extension](PostgreSQL_pg_cron.md). As another example, you can log query execution plans by loading the `auto_explain` module. To learn more, see [Logging execution plans of queries](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) in the AWS knowledge center.
An extension that provides access to external data is more specifically known as a *foreign data wrapper* (FDW). As one example, the `oracle_fdw` extension allows your Aurora PostgreSQL DB cluster to work with Oracle databases.
You can also specify precisely which extensions can be installed on your Aurora PostgreSQL DB instance, by listing them in the `rds.allowed_extensions` parameter. For more information, see [Restricting installation of PostgreSQL extensions](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction.html).
Following, you can find information about setting up and using some of the extensions, modules, and FDWs available for Aurora PostgreSQL. For simplicity's sake, these are all referred to as "extensions." You can find listings of extensions that you can use with the currently available Aurora PostgreSQL versions, see [Extension versions for Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in the *Release Notes for Aurora PostgreSQL*.
+ [Managing large objects with the lo module](PostgreSQL_large_objects_lo_extension.md)
+ [Managing spatial data with the PostGIS extension](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md)
+ [Managing PostgreSQL partitions with the pg\$1partman extension](PostgreSQL_Partitions.md)
+ [Scheduling maintenance with the PostgreSQL pg\$1cron extension](PostgreSQL_pg_cron.md)
+ [Using pgAudit to log database activity](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md)
+ [Using pglogical to synchronize data across instances](Appendix.PostgreSQL.CommonDBATasks.pglogical.md)
+ [Working with Oracle databases by using the oracle\$1fdw extension](postgresql-oracle-fdw.md)
+ [Working with SQL Server databases by using the tds\$1fdw extension](postgresql-tds-fdw.md)
# Using Amazon Aurora delegated extension support for PostgreSQL
Using Amazon Aurora delegated extension support for PostgreSQL, you can delegate the extension management to a user who need not be an `rds_superuser`. With this delegated extension support, a new role called `rds_extension` is created and you must assign this to a user to manage other extensions. This role can create, update, and drop extensions.
You can specify the extensions that can be installed on your Aurora PostgreSQL DB instance, by listing them in the `rds.allowed_extensions` parameter. For more information, see [Using PostgreSQL extensions with Amazon RDS for PostgreSQL](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Extensions.html).
You can restrict the list of extensions available that can be managed by the user with the `rds_extension` role using `rds.allowed_delegated_extensions` parameter.
The delegated extension support is available in the following versions:
+ All higher versions
+ 15.5 and higher 15 versions
+ 14.10 and higher 14 versions
+ 13.13 and higher 13 versions
+ 12.17 and higher 12 versions
**Topics**
+ [Turning on delegate extension support to a user](#AuroraPostgreSQL.delegated_ext_mgmt)
+ [Configuration used in Aurora delegated extension support for PostgreSQL](#AuroraPostgreSQL.delegated_ext_config)
+ [Turning off the support for the delegated extension](#AuroraPostgreSQL.delegated_ext_disable)
+ [Benefits of using Amazon Aurora delegated extension support](#AuroraPostgreSQL.delegated_ext_benefits)
+ [Limitation of Aurora delegated extension support for PostgreSQL](#AuroraPostgreSQL.delegated_ext_limit)
+ [Permissions required for certain extensions](#AuroraPostgreSQL.delegated_ext_perm)
+ [Security Considerations](#AuroraPostgreSQL.delegated_ext_sec)
+ [Drop extension cascade disabled](#AuroraPostgreSQL.delegated_ext_drop)
+ [Example extensions that can be added using delegated extension support](#AuroraPostgreSQL.delegated_ext_support)
## Turning on delegate extension support to a user
You must perform the following to enable delegate extension support to a user:
1. **Grant `rds_extension` role to a user** – Connect to the database as `rds_superuser` and execute the following command:
```
Postgres => grant rds_extension to user_name;
```
1. **Set the list of extensions available for delegated users to manage** – The `rds.allowed_delegated_extensions` allows you to specify a subset of the available extensions using `rds.allowed_extensions` in the DB cluster parameter. You can perform this at one of the following levels:
+ In the cluster or the instance parameter group, through the AWS Management Console or API. For more information, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).
+ Use the following command at the database level:
```
alter database database_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
+ Use the following command at the user level:
```
alter user user_name set rds.allowed_delegated_extensions = 'extension_name_1,
extension_name_2,...extension_name_n';
```
**Note**
You need not restart the database after changing the `rds.allowed_delegated_extensions` dynamic parameter.
1. **Allow access to the delegated user to objects created during the extension creation process** – Certain extensions create objects that require additional permissions to be granted before the user with `rds_extension` role can access them. The `rds_superuser` must grant the delegated user access to those objects. One of the options is to use an event trigger to automatically grant permission to the delegated user.
**Example of event trigger**
If you want to allow a delegated user with `rds_extension` to use extensions that require setting permissions on their objects created by the extension creation, you can customize the below example of an event trigger and add only the extensions for which you want the delegated users to have access to the full functionality. This event trigger can be created on template1 (the default template), therefore all database created from template1 will have that event trigger. When a delegated user installs the extension, this trigger will automatically grant ownership on the objects created by the extension.
```
CREATE OR REPLACE FUNCTION create_ext()
RETURNS event_trigger AS $$
DECLARE
schemaname TEXT;
databaseowner TEXT;
r RECORD;
BEGIN
IF tg_tag = 'CREATE EXTENSION' and current_user != 'rds_superuser' THEN
RAISE NOTICE 'SECURITY INVOKER';
RAISE NOTICE 'user: %', current_user;
FOR r IN SELECT * FROM pg_catalog.pg_event_trigger_ddl_commands()
LOOP
CONTINUE WHEN r.command_tag != 'CREATE EXTENSION' OR r.object_type != 'extension';
schemaname = (
SELECT n.nspname
FROM pg_catalog.pg_extension AS e
INNER JOIN pg_catalog.pg_namespace AS n
ON e.extnamespace = n.oid
WHERE e.oid = r.objid
);
databaseowner = (
SELECT pg_catalog.pg_get_userbyid(d.datdba)
FROM pg_catalog.pg_database d
WHERE d.datname = current_database()
);
RAISE NOTICE 'Record for event trigger %, objid: %,tag: %, current_user: %, schema: %, database_owenr: %', r.object_identity, r.objid, tg_tag, current_user, schemaname, databaseowner;
IF r.object_identity = 'address_standardizer_data_us' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_gaz TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_lex TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.us_rules TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'dict_int' THEN
EXECUTE pg_catalog.format('ALTER TEXT SEARCH DICTIONARY %I.intdict OWNER TO %I;', schemaname, databaseowner);
ELSIF r.object_identity = 'pg_partman' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.part_config_sub TO %I WITH GRANT OPTION;', schemaname, databaseowner);
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE %I.custom_time_partitions TO %I WITH GRANT OPTION;', schemaname, databaseowner);
ELSIF r.object_identity = 'postgis_topology' THEN
EXECUTE pg_catalog.format('GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
EXECUTE pg_catalog.format('GRANT USAGE ON SCHEMA topology TO %I WITH GRANT OPTION;', databaseowner);
END IF;
END LOOP;
END IF;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;
CREATE EVENT TRIGGER log_create_ext ON ddl_command_end EXECUTE PROCEDURE create_ext();
```
## Configuration used in Aurora delegated extension support for PostgreSQL
| Configuration Name | Description | Default Value | Notes | Who can modify or grant permission |
| --- | --- | --- | --- | --- |
| `rds.allowed_delegated_extensions` | This parameter limits the extensions a rds\$1extension role can manage in a database. It must be a subset of rds.allowed\$1extensions. | empty string | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora_delegated_ext.html) To learn more about setting up this parameter, see [Turning on delegate extension support to a user](#AuroraPostgreSQL.delegated_ext_mgmt). | rds\$1superuser |
| `rds.allowed_extensions` | This parameter lets the customer limit the extensions that can be installed in the Aurora PostgreSQL DB instance. For more information, see [Restricting installation of PostgreSQL extensions ](https://docs.aws.amazon.com//AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.Restriction) | "\$1" | By default, this parameter is set to "\$1", which means that all extensions supported on RDS for PostgreSQL and Aurora PostgreSQL are allowed to be created by users with necessary privileges. Empty means no extensions can be installed in the Aurora PostgreSQL DB instance. | administrator |
| `rds-delegated_extension_allow_drop_cascade` | This parameter controls the ability for user with `rds_extension` to drop the extension using a cascade option. | off | By default, `rds-delegated_extension_allow_drop_cascade` is set to `off`. This means that users with `rds_extension` are not allowed to drop an extension using the cascade option. To grant that ability, the `rds.delegated_extension_allow_drop_cascade` parameter should be set to `on`. | rds\$1superuser |
## Turning off the support for the delegated extension
**Turning off partially**
The delegated users can’t create new extensions but can still update existing extensions.
+ Reset `rds.allowed_delegated_extensions` to the default value in the DB cluster parameter group.
+ Use the following command at the database level:
```
alter database database_name reset rds.allowed_delegated_extensions;
```
+ Use the following command at the user level:
```
alter user user_name reset rds.allowed_delegated_extensions;
```
**Turning off fully**
Revoking `rds_extension` role from a user will revert the user to standard permissions. The user can no longer create, update, or drop extensions.
```
postgres => revoke rds_extension from user_name;
```
## Benefits of using Amazon Aurora delegated extension support
By using Amazon Aurora delegated extension support for PostgreSQL, you securely delegate the extension management to users who do not have the `rds_superuser` role. This feature provides the following benefits:
+ You can easily delegate extension management to users of your choice.
+ This doesn’t require `rds_superuser` role.
+ Provides ability to support different set of extensions for different databases in the same DB cluster.
## Limitation of Aurora delegated extension support for PostgreSQL
+ Objects created during the extension creation process may require additional privileges for the extension to function properly.
## Permissions required for certain extensions
In order to create, use, or update the following extensions, the delegated user should have the necessary privileges on the following functions, tables, and schema.
| Extensions that need ownership or permissions | Function | Tables | Schema | Text Search Dictionary | Comment |
| --- | --- | --- | --- | --- | --- |
| address\$1standardizer\$1data\$1us | | us\$1gaz, us\$1lex, us\$1lex, I.us\$1rules | | | |
| amcheck | bt\$1index\$1check, bt\$1index\$1parent\$1check | | | | |
| dict\$1int | | | | intdict | |
| pg\$1partman | | custom\$1time\$1partitions, part\$1config, part\$1config\$1sub | | | |
| pg\$1stat\$1statements | | | | | |
| PostGIS | st\$1tileenvelope | spatial\$1ref\$1sys | | | |
| postgis\$1raster | | | | | |
| postgis\$1topology | | topology, layer | topology | | the delegated user Must be the database owner |
| log\$1fdw | create\$1foreign\$1table\$1for\$1log\$1file | | | | |
| rds\$1tools | role\$1password\$1encryption\$1type | | | | |
| postgis\$1tiger\$1geocoder | | geocode\$1settings\$1default, geocode\$1settings | tiger | | |
| pg\$1freespacemap | pg\$1freespace | | | | |
| pg\$1visibility | pg\$1visibility | | | | |
## Security Considerations
Keep in mind that a user with `rds_extension` role will be able to manage extensions on all databases they have the connect privilege on. If the intention is to have a delegated user manage extension on a single database, a good practice is to revoke all privileges from public on each database, then explicitly grant the connect privilege for that specific database to the delegate user.
There are several extensions that can allow a user to access information from multiple database. Ensure the users you grant `rds_extension` has cross database capabilities before adding these extensions to `rds.allowed_delegated_extensions`. For example, `postgres_fdw` and `dblink` provide functionality to query across databases on the same instance or remote instances. `log_fdw` reads the postgres engine log files, which are for all databases in the instance, potentially containing slow queries or error messages from multiple databases. `pg_cron` enables running scheduled background jobs on the DB instance and can configure jobs to run in a different database.
## Drop extension cascade disabled
The ability to drop the extension with cascade option by a user with the `rds_extension` role is controlled by `rds.delegated_extension_allow_drop_cascade` parameter. By default, `rds-delegated_extension_allow_drop_cascade` is set to `off`. This means that users with the `rds_extension` role are not allowed to drop an extension using the cascade option as shown in the below query.
```
DROP EXTENSION CASCADE;
```
As this will automatically drop objects that depend on the extension, and in turn all objects that depend on those objects. Attempting to use the cascade option will result in an error.
To grant that ability, the `rds.delegated_extension_allow_drop_cascade` parameter should be set to `on`.
Changing the `rds.delegated_extension_allow_drop_cascade` dynamic parameter doesn't require a database restart. You can do this at one of the following levels:
+ In the cluster or the instance parameter group, through the AWS Management Console or API.
+ Using the following command at the database level:
```
alter database database_name set rds.delegated_extension_allow_drop_cascade = 'on';
```
+ Using the following command at the user level:
```
alter role tenant_user set rds.delegated_extension_allow_drop_cascade = 'on';
```
## Example extensions that can be added using delegated extension support
+ `rds_tools`
```
extension_test_db=> create extension rds_tools;
CREATE EXTENSION
extension_test_db=> SELECT * from rds_tools.role_password_encryption_type() where rolname = 'pg_read_server_files';
ERROR: permission denied for function role_password_encryption_type
```
+ `amcheck`
```
extension_test_db=> CREATE TABLE amcheck_test (id int);
CREATE TABLE
extension_test_db=> INSERT INTO amcheck_test VALUES (generate_series(1,100000));
INSERT 0 100000
extension_test_db=> CREATE INDEX amcheck_test_btree_idx ON amcheck_test USING btree (id);
CREATE INDEX
extension_test_db=> create extension amcheck;
CREATE EXTENSION
extension_test_db=> SELECT bt_index_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_check
extension_test_db=> SELECT bt_index_parent_check('amcheck_test_btree_idx'::regclass);
ERROR: permission denied for function bt_index_parent_check
```
+ `pg_freespacemap`
```
extension_test_db=> create extension pg_freespacemap;
CREATE EXTENSION
extension_test_db=> SELECT * FROM pg_freespace('pg_authid');
ERROR: permission denied for function pg_freespace
extension_test_db=> SELECT * FROM pg_freespace('pg_authid',0);
ERROR: permission denied for function pg_freespace
```
+ `pg_visibility`
```
extension_test_db=> create extension pg_visibility;
CREATE EXTENSION
extension_test_db=> select * from pg_visibility('pg_database'::regclass);
ERROR: permission denied for function pg_visibility
```
+ `postgres_fdw`
```
extension_test_db=> create extension postgres_fdw;
CREATE EXTENSION
extension_test_db=> create server myserver foreign data wrapper postgres_fdw options (host 'foo', dbname 'foodb', port '5432');
ERROR: permission denied for foreign-data wrapper postgres_fdw
```
# Managing large objects with the lo module
The lo module (extension) is for database users and developers working with PostgreSQL databases through JDBC or ODBC drivers. Both JDBC and ODBC expect the database to handle deletion of large objects when references to them change. However, PostgreSQL doesn't work that way. PostgreSQL doesn't assume that an object should be deleted when its reference changes. The result is that objects remain on disk, unreferenced. The lo extension includes a function that you use to trigger on reference changes to delete objects if needed.
**Tip**
To determine if your database can benefit from the lo extension, use the `vacuumlo` utility to check for orphaned large objects. To get counts of orphaned large objects without taking any action, run the utility with the `-n` option (no-op). To learn how, see [vacuumlo utility](#vacuumlo-utility) following.
The lo module is available for Aurora PostgreSQL 13.7, 12.11, 11.16, 10.21 and higher minor versions.
To install the module (extension), you need `rds_superuser` privileges. Installing the lo extension adds the following to your database:
+ `lo` – This is a large object (lo) data type that you can use for binary large objects (BLOBs) and other large objects. The `lo` data type is a domain of the `oid` data type. In other words, it's an object identifier with optional constraints. For more information, see [Object identifiers](https://www.postgresql.org/docs/14/datatype-oid.html) in the PostgreSQL documentation. In simple terms, you can use the `lo` data type to distinguish your database columns that hold large object references from other object identifiers (OIDs).
+ `lo_manage` – This is a function that you can use in triggers on table columns that contain large object references. Whenever you delete or modify a value that references a large object, the trigger unlinks the object (`lo_unlink`) from its reference. Use the trigger on a column only if the column is the sole database reference to the large object.
For more information about the large objects module, see [lo](https://www.postgresql.org/docs/current/lo.html) in the PostgreSQL documentation.
## Installing the lo extension
Before installing the lo extension, make sure that you have `rds_superuser` privileges.
**To install the lo extension**
1. Use `psql` to connect to the primary DB instance of your Aurora PostgreSQL DB cluster.
```
psql --host=your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
When prompted, enter your password. The `psql` client connects and displays the default administrative connection database, `postgres=>`, as the prompt.
1. Install the extension as follows.
```
postgres=> CREATE EXTENSION lo;
CREATE EXTENSION
```
You can now use the `lo` data type to define columns in your tables. For example, you can create a table (`images`) that contains raster image data. You can use the `lo` data type for a column `raster`, as shown in the following example, which creates a table.
```
postgres=> CREATE TABLE images (image_name text, raster lo);
```
## Using the lo\$1manage trigger function to delete objects
You can use the `lo_manage` function in a trigger on a `lo` or other large object columns to clean up (and prevent orphaned objects) when the `lo` is updated or deleted.
**To set up triggers on columns that reference large objects**
+ Do one of the following:
+ Create a BEFORE UPDATE OR DELETE trigger on each column to contain unique references to large objects, using the column name for the argument.
```
postgres=> CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON images
FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);
```
+ Apply a trigger only when the column is being updated.
```
postgres=> CREATE TRIGGER t_raster BEFORE UPDATE OF images
FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);
```
The `lo_manage` trigger function works only in the context of inserting or deleting column data, depending on how you define the trigger. It has no effect when you perform a `DROP` or `TRUNCATE` operation on a database. That means that you should delete object columns from any tables before dropping, to prevent creating orphaned objects.
For example, suppose that you want to drop the database containing the `images` table. You delete the column as follows.
```
postgres=> DELETE FROM images COLUMN raster
```
Assuming that the `lo_manage` function is defined on that column to handle deletes, you can now safely drop the table.
## Removing orphaned large objects using `vacuumlo`
The `vacuumlo` utility identifies and removes orphaned large objects from databases. This utility has been available since PostgreSQL 9.1.24. If your database users routinely work with large objects, we recommend that you run `vacuumlo` occasionally to clean up orphaned large objects.
Before installing the lo extension, you can use `vacuumlo` to assess whether your Aurora PostgreSQL DB cluster can benefit. To do so, run `vacuumlo` with the `-n` option (no-op) to show what would be removed, as shown in the following:
```
$ vacuumlo -v -n -h your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com -p 5433 -U postgres docs-lab-spatial-db
Password:*****
Connected to database "docs-lab-spatial-db"
Test run: no large objects will be removed!
Would remove 0 large objects from database "docs-lab-spatial-db".
```
As the output shows, orphaned large objects aren't a problem for this particular database.
For more information about this utility, see [https://www.postgresql.org/docs/current/vacuumlo.html](https://www.postgresql.org/docs/current/vacuumlo.html) in the PostgreSQL documentation.
## Understanding how `vacuumlo` works
The `vacuumlo` command removes orphaned large objects (LOs) from your PostgreSQL database without affecting or conflicting with your user tables.
The command works as follows:
1. `vacuumlo` starts by creating a temporary table containing all the Object IDs (OIDs) of the large objects in your database.
1. `vacuumlo` then scans through every column in the database that uses the data types `oid` or `lo`. If `vacuumlo` finds a matching OID in these columns, it removes the OID from the temporary table. `vacuumlo` checks only columns specifically named `oid` or `lo`, not domains based on these types.
1. The remaining entries in the temporary table represent orphaned LOs, which `vacuumlo` then safely removes.
## Improving `vacuumlo` performance
You can potentially improve the performance of `vacuumlo` by increasing the batch size using the `-l` option. This allows `vacuumlo` to process more LOs at once.
If your system has sufficient memory and you can accommodate the temporary table completely in memory, increasing the `temp_buffers` setting at the database level may improve performance. This allows the table to reside entirely in memory, which can enhance the overall performance.
Following query estimates the size of the temporary table:
```
SELECT
pg_size_pretty(SUM(pg_column_size(oid))) estimated_lo_temp_table_size
FROM
pg_largeobject_metadata;
```
## Considerations for large objects
Following you can find some important considerations to note when working with large objects:
+ `Vacuumlo` is the only solution as there is currently no other method to remove orphaned LOs.
+ Tools like pglogical, native logical replication, and AWS DMS that use replication technologies do not support replicating large objects.
+ When designing your database schema, avoid using large objects when possible and consider using alternative data types like `bytea` instead.
+ Run `vacuumlo` regularly, at least weekly, to prevent issues with orphaned LOs.
+ Use a trigger with the `lo_manage` function on tables that store large objects to help prevent orphaned LOs from being created.
# Managing spatial data with the PostGIS extension
PostGIS is an extension to PostgreSQL for storing and managing spatial information. To learn more about PostGIS, see [PostGIS.net](https://postgis.net/).
Starting with version 10.5, PostgreSQL supports the libprotobuf 1.3.0 library used by PostGIS for working with map box vector tile data.
Setting up the PostGIS extension requires `rds_superuser` privileges. We recommend that you create a user (role) to manage the PostGIS extension and your spatial data. The PostGIS extension and its related components add thousands of functions to PostgreSQL. Consider creating the PostGIS extension in its own schema if that makes sense for your use case. The following example shows how to install the extension in its own database, but this isn't required.
**Topics**
+ [Step 1: Create a user (role) to manage the PostGIS extension](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Connect)
+ [Step 2: Load the PostGIS extensions](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.LoadExtensions)
+ [Step 3: Transfer ownership of the extension schemas](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferOwnership)
+ [Step 4: Transfer ownership of the PostGIS tables](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.TransferObjects)
+ [Step 5: Test the extensions](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Test)
+ [Step 6: Upgrade the PostGIS extension](#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)
+ [PostGIS extension versions](#CHAP_PostgreSQL.Extensions.PostGIS)
+ [Upgrading PostGIS 2 to PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3)
## Step 1: Create a user (role) to manage the PostGIS extension
First, connect to your RDS for PostgreSQL DB instance as a user that has `rds_superuser` privileges. If you kept the default name when you set up your instance, you connect as `postgres`.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Create a separate role (user) to administer the PostGIS extension.
```
postgres=> CREATE ROLE gis_admin LOGIN PASSWORD 'change_me';
CREATE ROLE
```
Grant this role `rds_superuser` privileges, to allow the role to install the extension.
```
postgres=> GRANT rds_superuser TO gis_admin;
GRANT
```
Create a database to use for your PostGIS artifacts. This step is optional. Or you can create a schema in your user database for the PostGIS extensions, but this also isn't required.
```
postgres=> CREATE DATABASE lab_gis;
CREATE DATABASE
```
Give the `gis_admin` all privileges on the `lab_gis` database.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_gis TO gis_admin;
GRANT
```
Exit the session and reconnect to your RDS for PostgreSQL DB instance as `gis_admin`.
```
postgres=> psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=gis_admin --password --dbname=lab_gis
Password for user gis_admin:...
lab_gis=>
```
Continue setting up the extension as detailed in the next steps.
## Step 2: Load the PostGIS extensions
The PostGIS extension includes several related extensions that work together to provide geospatial functionality. Depending on your use case, you might not need all the extensions created in this step.
Use `CREATE EXTENSION` statements to load the PostGIS extensions.
```
CREATE EXTENSION postgis;
CREATE EXTENSION
CREATE EXTENSION postgis_raster;
CREATE EXTENSION
CREATE EXTENSION fuzzystrmatch;
CREATE EXTENSION
CREATE EXTENSION postgis_tiger_geocoder;
CREATE EXTENSION
CREATE EXTENSION postgis_topology;
CREATE EXTENSION
CREATE EXTENSION address_standardizer_data_us;
CREATE EXTENSION
```
You can verify the results by running the SQL query shown in the following example, which lists the extensions and their owners.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+-----------
public | postgres
tiger | rdsadmin
tiger_data | rdsadmin
topology | rdsadmin
(4 rows)
```
## Step 3: Transfer ownership of the extension schemas
Use the ALTER SCHEMA statements to transfer ownership of the schemas to the `gis_admin` role.
```
ALTER SCHEMA tiger OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA tiger_data OWNER TO gis_admin;
ALTER SCHEMA
ALTER SCHEMA topology OWNER TO gis_admin;
ALTER SCHEMA
```
You can confirm the ownership change by running the following SQL query. Or you can use the `\dn` metacommand from the psql command line.
```
SELECT n.nspname AS "Name",
pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner"
FROM pg_catalog.pg_namespace n
WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
ORDER BY 1;
List of schemas
Name | Owner
--------------+---------------
public | postgres
tiger | gis_admin
tiger_data | gis_admin
topology | gis_admin
(4 rows)
```
## Step 4: Transfer ownership of the PostGIS tables
**Note**
Do not change ownership of the PostGIS functions. Proper operation and future upgrades of PostGIS require these functions to retain original ownership. For more information about PostGIS permissions, see [PostgreSQL Security](https://postgis.net/workshops/postgis-intro/security.html).
Use the following function to transfer ownership of the PostGIS tables to the `gis_admin` role. Run the following statement from the psql prompt to create the function.
```
CREATE FUNCTION exec(text) returns text language plpgsql volatile AS $f$ BEGIN EXECUTE $1; RETURN $1; END; $f$;
CREATE FUNCTION
```
Next, run the following query to run the `exec` function that in turn runs the statements and alters the permissions.
```
SELECT exec('ALTER TABLE ' || quote_ident(s.nspname) || '.' || quote_ident(s.relname) || ' OWNER TO gis_admin;')
FROM (
SELECT nspname, relname
FROM pg_class c JOIN pg_namespace n ON (c.relnamespace = n.oid)
WHERE nspname in ('tiger','topology') AND
relkind IN ('r','S','v') ORDER BY relkind = 'S')
s;
```
## Step 5: Test the extensions
To avoid needing to specify the schema name, add the `tiger` schema to your search path using the following command.
```
SET search_path=public,tiger;
SET
```
Test the `tiger` schema by using the following SELECT statement.
```
SELECT address, streetname, streettypeabbrev, zip
FROM normalize_address('1 Devonshire Place, Boston, MA 02109') AS na;
address | streetname | streettypeabbrev | zip
---------+------------+------------------+-------
1 | Devonshire | Pl | 02109
(1 row)
```
To learn more about this extension, see [Tiger Geocoder](https://postgis.net/docs/Extras.html#Tiger_Geocoder) in the PostGIS documentation.
Test access to the `topology` schema by using the following `SELECT` statement. This calls the `createtopology` function to register a new topology object (my\$1new\$1topo) with the specified spatial reference identifier (26986) and default tolerance (0.5). To learn more, see [CreateTopology](https://postgis.net/docs/CreateTopology.html) in the PostGIS documentation.
```
SELECT topology.createtopology('my_new_topo',26986,0.5);
createtopology
----------------
1
(1 row)
```
## Step 6: Upgrade the PostGIS extension
Each new release of PostgreSQL supports one or more versions of the PostGIS extension compatible with that release. Upgrading the PostgreSQL engine to a new version doesn't automatically upgrade the PostGIS extension. Before upgrading the PostgreSQL engine, you typically upgrade PostGIS to the newest available version for the current PostgreSQL version. For details, see [PostGIS extension versions](#CHAP_PostgreSQL.Extensions.PostGIS).
After the PostgreSQL engine upgrade, you then upgrade the PostGIS extension again, to the version supported for the newly upgraded PostgreSQL engine version. For more information about upgrading the PostgreSQL engine, see [Testing an upgrade of your production DB cluster to a new major version](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
You can check for available PostGIS extension version updates on your Aurora PostgreSQL DB cluster at any time. To do so, run the following command. This function is available with PostGIS 2.5.0 and higher versions.
```
SELECT postGIS_extensions_upgrade();
```
If your application doesn't support the latest PostGIS version, you can install an older version of PostGIS that's available in your major version as follows.
```
CREATE EXTENSION postgis VERSION "2.5.5";
```
If you want to upgrade to a specific PostGIS version from an older version, you can also use the following command.
```
ALTER EXTENSION postgis UPDATE TO "2.5.5";
```
Depending on the version that you're upgrading from, you might need to use this function again. The result of the first run of the function determines if an additional upgrade function is needed. For example, this is the case for upgrading from PostGIS 2 to PostGIS 3. For more information, see [Upgrading PostGIS 2 to PostGIS 3](#PostgreSQL.Extensions.PostGIS.versions.upgrading.2-to-3).
If you upgraded this extension to prepare for a major version upgrade of the PostgreSQL engine, you can continue with other preliminary tasks. For more information, see [Testing an upgrade of your production DB cluster to a new major version](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
## PostGIS extension versions
We recommend that you install the versions of all extensions such as PostGIS as listed in [Extension versions for Aurora PostgreSQL-Compatible Edition](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in the *Release Notes for Aurora PostgreSQL*. To get a list of versions that are available in your release, use the following command.
```
SELECT * FROM pg_available_extension_versions WHERE name='postgis';
```
You can find version information in the following sections in the *Release Notes for Aurora PostgreSQL*:
+ [Extension versions for Aurora PostgreSQL 14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.14)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.13)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.12)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.11)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.10)
+ [Extension versions for Aurora PostgreSQL-Compatible Edition 9.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html#AuroraPostgreSQL.Extensions.96)
## Upgrading PostGIS 2 to PostGIS 3
Starting with version 3.0, the PostGIS raster functionality is now a separate extension, `postgis_raster`. This extension has its own installation and upgrade path. This removes dozens of functions, data types, and other artifacts required for raster image processing from the core `postgis` extension. That means that if your use case doesn't require raster processing, you don't need to install the `postgis_raster` extension.
In the following upgrade example, the first upgrade command extracts raster functionality into the `postgis_raster` extension. A second upgrade command is then required to upgrade `postgis_raster` to the new version.
**To upgrade from PostGIS 2 to PostGIS 3**
1. Identify the default version of PostGIS that's available to the PostgreSQL version on your Aurora PostgreSQL DB cluster. To do so, run the following query.
```
SELECT * FROM pg_available_extensions
WHERE default_version > installed_version;
name | default_version | installed_version | comment
---------+-----------------+-------------------+------------------------------------------------------------
postgis | 3.1.4 | 2.3.7 | PostGIS geometry and geography spatial types and functions
(1 row)
```
1. Identify the versions of PostGIS installed in each database on the writer instance of your Aurora PostgreSQL DB cluster. In other words, query each user database as follows.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
---------+---------+--------+---------------------------------------------------------------------
postgis | 2.3.7 | public | PostGIS geometry, geography, and raster spatial types and functions
(1 row)
```
This mismatch between the default version (PostGIS 3.1.4) and the installed version (PostGIS 2.3.7) means that you need to upgrade the PostGIS extension.
```
ALTER EXTENSION postgis UPDATE;
ALTER EXTENSION
WARNING: unpackaging raster
WARNING: PostGIS Raster functionality has been unpackaged
```
1. Run the following query to verify that the raster functionality is now in its own package.
```
SELECT
probin,
count(*)
FROM
pg_proc
WHERE
probin LIKE '%postgis%'
GROUP BY
probin;
probin | count
--------------------------+-------
$libdir/rtpostgis-2.3 | 107
$libdir/postgis-3 | 487
(2 rows)
```
The output shows that there's still a difference between versions. The PostGIS functions are version 3 (postgis-3), while the raster functions (rtpostgis) are version 2 (rtpostgis-2.3). To complete the upgrade, you run the upgrade command again, as follows.
```
postgres=> SELECT postgis_extensions_upgrade();
```
You can safely ignore the warning messages. Run the following query again to verify that the upgrade is complete. The upgrade is complete when PostGIS and all related extensions aren't marked as needing upgrade.
```
SELECT postgis_full_version();
```
1. Use the following query to see the completed upgrade process and the separately packaged extensions, and verify that their versions match.
```
SELECT
e.extname AS "Name",
e.extversion AS "Version",
n.nspname AS "Schema",
c.description AS "Description"
FROM
pg_catalog.pg_extension e
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = e.extnamespace
LEFT JOIN pg_catalog.pg_description c ON c.objoid = e.oid
AND c.classoid = 'pg_catalog.pg_extension'::pg_catalog.regclass
WHERE
e.extname LIKE '%postgis%'
ORDER BY
1;
Name | Version | Schema | Description
----------------+---------+--------+---------------------------------------------------------------------
postgis | 3.1.5 | public | PostGIS geometry, geography, and raster spatial types and functions
postgis_raster | 3.1.5 | public | PostGIS raster types and functions
(2 rows)
```
The output shows that the PostGIS 2 extension was upgraded to PostGIS 3, and both `postgis` and the now separate `postgis_raster` extension are version 3.1.5.
After this upgrade completes, if you don't plan to use the raster functionality, you can drop the extension as follows.
```
DROP EXTENSION postgis_raster;
```
# Managing PostgreSQL partitions with the pg\$1partman extension
PostgreSQL table partitioning provides a framework for high-performance handling of data input and reporting. Use partitioning for databases that require very fast input of large amounts of data. Partitioning also provides for faster queries of large tables. Partitioning helps maintain data without impacting the database instance because it requires less I/O resources.
By using partitioning, you can split data into custom-sized chunks for processing. For example, you can partition time-series data for ranges such as hourly, daily, weekly, monthly, quarterly, yearly, custom, or any combination of these. For a time-series data example, if you partition the table by hour, each partition contains one hour of data. If you partition the time-series table by day, the partitions holds one day's worth of data, and so on. The partition key controls the size of a partition.
When you use an `INSERT` or `UPDATE` SQL command on a partitioned table, the database engine routes the data to the appropriate partition. PostgreSQL table partitions that store the data are child tables of the main table.
During database query reads, the PostgreSQL optimizer examines the `WHERE` clause of the query and, if possible, directs the database scan to only the relevant partitions.
Starting with version 10, PostgreSQL uses declarative partitioning to implement table partitioning. This is also known as native PostgreSQL partitioning. Before PostgreSQL version 10, you used triggers to implement partitions.
PostgreSQL table partitioning provides the following features:
+ Creation of new partitions at any time.
+ Variable partition ranges.
+ Detachable and reattachable partitions using data definition language (DDL) statements.
For example, detachable partitions are useful for removing historical data from the main partition but keeping historical data for analysis.
+ New partitions inherit the parent database table properties, including the following:
+ Indexes
+ Primary keys, which must include the partition key column
+ Foreign keys
+ Check constraints
+ References
+ Creating indexes for the full table or each specific partition.
You can't alter the schema for an individual partition. However, you can alter the parent table (such as adding a new column), which propagates to partitions.
**Topics**
+ [Overview of the PostgreSQL pg\$1partman extension](#PostgreSQL_Partitions.pg_partman)
+ [Enabling the pg\$1partman extension](#PostgreSQL_Partitions.enable)
+ [Configuring partitions using the create\$1parent function](#PostgreSQL_Partitions.create_parent)
+ [Configuring partition maintenance using the run\$1maintenance\$1proc function](#PostgreSQL_Partitions.run_maintenance_proc)
## Overview of the PostgreSQL pg\$1partman extension
You can use the PostgreSQL `pg_partman` extension to automate the creation and maintenance of table partitions. For more general information, see [PG Partition Manager](https://github.com/pgpartman/pg_partman) in the `pg_partman` documentation.
**Note**
The `pg_partman` extension is supported on Aurora PostgreSQL versions 12.6 and higher.
Instead of having to manually create each partition, you configure `pg_partman` with the following settings:
+ Table to be partitioned
+ Partition type
+ Partition key
+ Partition granularity
+ Partition precreation and management options
After you create a PostgreSQL partitioned table, you register it with `pg_partman` by calling the `create_parent` function. Doing this creates the necessary partitions based on the parameters you pass to the function.
The `pg_partman` extension also provides the `run_maintenance_proc` function, which you can call on a scheduled basis to automatically manage partitions. To ensure that the proper partitions are created as needed, schedule this function to run periodically (such as hourly). You can also ensure that partitions are automatically dropped.
## Enabling the pg\$1partman extension
If you have multiple databases inside the same PostgreSQL DB instance for which you want to manage partitions, enable the `pg_partman` extension separately for each database. To enable the `pg_partman` extension for a specific database, create the partition maintenance schema and then create the `pg_partman` extension as follows.
```
CREATE SCHEMA partman;
CREATE EXTENSION pg_partman WITH SCHEMA partman;
```
**Note**
To create the `pg_partman` extension, make sure that you have `rds_superuser` privileges.
If you receive an error such as the following, grant the `rds_superuser` privileges to the account or use your superuser account.
```
ERROR: permission denied to create extension "pg_partman"
HINT: Must be superuser to create this extension.
```
To grant `rds_superuser` privileges, connect with your superuser account and run the following command.
```
GRANT rds_superuser TO user-or-role;
```
For the examples that show using the pg\$1partman extension, we use the following sample database table and partition. This database uses a partitioned table based on a timestamp. A schema `data_mart` contains a table named `events` with a column named `created_at`. The following settings are included in the `events` table:
+ Primary keys `event_id` and `created_at`, which must have the column used to guide the partition.
+ A check constraint `ck_valid_operation` to enforce values for an `operation` table column.
+ Two foreign keys, where one (`fk_orga_membership)` points to the external table `organization` and the other (`fk_parent_event_id`) is a self-referenced foreign key.
+ Two indexes, where one (`idx_org_id`) is for the foreign key and the other (`idx_event_type`) is for the event type.
The following DDL statements create these objects, which are automatically included on each partition.
```
CREATE SCHEMA data_mart;
CREATE TABLE data_mart.organization ( org_id BIGSERIAL,
org_name TEXT,
CONSTRAINT pk_organization PRIMARY KEY (org_id)
);
CREATE TABLE data_mart.events(
event_id BIGSERIAL,
operation CHAR(1),
value FLOAT(24),
parent_event_id BIGINT,
event_type VARCHAR(25),
org_id BIGSERIAL,
created_at timestamp,
CONSTRAINT pk_data_mart_event PRIMARY KEY (event_id, created_at),
CONSTRAINT ck_valid_operation CHECK (operation = 'C' OR operation = 'D'),
CONSTRAINT fk_orga_membership
FOREIGN KEY(org_id)
REFERENCES data_mart.organization (org_id),
CONSTRAINT fk_parent_event_id
FOREIGN KEY(parent_event_id, created_at)
REFERENCES data_mart.events (event_id,created_at)
) PARTITION BY RANGE (created_at);
CREATE INDEX idx_org_id ON data_mart.events(org_id);
CREATE INDEX idx_event_type ON data_mart.events(event_type);
```
## Configuring partitions using the create\$1parent function
After you enable the `pg_partman` extension, use the `create_parent` function to configure partitions inside the partition maintenance schema. The following example uses the `events` table example created in [Enabling the pg\$1partman extensionConfiguring partition maintenance using the run\$1maintenance\$1proc function](#PostgreSQL_Partitions.enable). Call the `create_parent` function as follows.
```
SELECT partman.create_parent(
p_parent_table => 'data_mart.events',
p_control => 'created_at',
p_type => 'range',
p_interval => '1 day',
p_premake => 30);
```
The parameters are as follows:
+ `p_parent_table` – The parent partitioned table. This table must already exist and be fully qualified, including the schema.
+ `p_control` – The column on which the partitioning is to be based. The data type must be an integer or time-based.
+ `p_type` – The type is either `'range'` or `'list'`.
+ `p_interval` – The time interval or integer range for each partition. Example values include `1 day`, `1 hour`, and so on.
+ `p_premake` – The number of partitions to create in advance to support new inserts.
For a complete description of the `create_parent` function, see [Creation Functions](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#user-content-creation-functions) in the `pg_partman` documentation.
## Configuring partition maintenance using the run\$1maintenance\$1proc function
You can run partition maintenance operations to automatically create new partitions, detach partitions, or remove old partitions. Partition maintenance relies on the `run_maintenance_proc` function of the `pg_partman` extension and the `pg_cron` extension, which initiates an internal scheduler. The `pg_cron` scheduler automatically executes SQL statements, functions, and procedures defined in your databases.
The following example uses the `events` table example created in [Enabling the pg\$1partman extensionConfiguring partition maintenance using the run\$1maintenance\$1proc function](#PostgreSQL_Partitions.enable) to set partition maintenance operations to run automatically. As a prerequisite, add `pg_cron` to the `shared_preload_libraries` parameter in the DB instance's parameter group.
```
CREATE EXTENSION pg_cron;
UPDATE partman.part_config
SET infinite_time_partitions = true,
retention = '3 months',
retention_keep_table=true
WHERE parent_table = 'data_mart.events';
SELECT cron.schedule('@hourly', $$CALL partman.run_maintenance_proc()$$);
```
Following, you can find a step-by-step explanation of the preceding example:
1. Modify the parameter group associated with your DB instance and add `pg_cron` to the `shared_preload_libraries` parameter value. This change requires a DB instance restart for it to take effect. For more information, see [Modifying parameters in a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
1. Run the command `CREATE EXTENSION pg_cron;` using an account that has the `rds_superuser` permissions. Doing this enables the `pg_cron` extension. For more information, see [Scheduling maintenance with the PostgreSQL pg\$1cron extension](PostgreSQL_pg_cron.md).
1. Run the command `UPDATE partman.part_config` to adjust the `pg_partman` settings for the `data_mart.events` table.
1. Run the command `SET` . . . to configure the `data_mart.events` table, with these clauses:
1. `infinite_time_partitions = true,` – Configures the table to be able to automatically create new partitions without any limit.
1. `retention = '3 months',` – Configures the table to have a maximum retention of three months.
1. `retention_keep_table=true `– Configures the table so that when the retention period is due, the table isn't deleted automatically. Instead, partitions that are older than the retention period are only detached from the parent table.
1. Run the command `SELECT cron.schedule` . . . to make a `pg_cron` function call. This call defines how often the scheduler runs the `pg_partman` maintenance procedure, `partman.run_maintenance_proc`. For this example, the procedure runs every hour.
For a complete description of the `run_maintenance_proc` function, see [Maintenance Functions](https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#maintenance-functions) in the `pg_partman` documentation.
# Scheduling maintenance with the PostgreSQL pg\$1cron extension
You can use the PostgreSQL `pg_cron` extension to schedule maintenance commands within a PostgreSQL database. For more information about the extension, see [What is pg\$1cron?](https://github.com/citusdata/pg_cron) in the pg\$1cron documentation.
The `pg_cron` extension is supported on Aurora PostgreSQL engine versions 12.6 and higher version
To learn more about using `pg_cron`, see [Schedule jobs with pg\$1cron on your RDS for PostgreSQL or your Aurora PostgreSQL-Compatible Edition databases](https://aws.amazon.com/blogs/database/schedule-jobs-with-pg_cron-on-your-amazon-rds-for-postgresql-or-amazon-aurora-for-postgresql-databases/).
**Note**
The `pg_cron` extension version is displayed as a two digit version, for example, 1.6, in the pg\$1available\$1extensions view. While you might see three digit versions, for example, 1.6.4 or 1.6.5, listed in some contexts, you must specify the two digit version when performing an extension upgrade.
**Topics**
+ [Setting up the pg\$1cron extension](#PostgreSQL_pg_cron.enable)
+ [Granting database users permissions to use pg\$1cron](#PostgreSQL_pg_cron.permissions)
+ [Scheduling pg\$1cron jobs](#PostgreSQL_pg_cron.examples)
+ [Reference for the pg\$1cron extension](#PostgreSQL_pg_cron.reference)
## Setting up the pg\$1cron extension
Set up the `pg_cron` extension as follows:
1. Modify the custom parameter group associated with your PostgreSQL DB instance by adding `pg_cron` to the `shared_preload_libraries` parameter value.
Restart the PostgreSQL DB instance to have changes to the parameter group take effect. To learn more about working with parameter groups, see [Amazon Aurora PostgreSQL parameters](AuroraPostgreSQL.Reference.ParameterGroups.md).
1. After the PostgreSQL DB instance has restarted, run the following command using an account that has `rds_superuser` permissions. For example, if you used the default settings when you created your Aurora PostgreSQL DB cluster, connect as user `postgres` and create the extension.
```
CREATE EXTENSION pg_cron;
```
The `pg_cron` scheduler is set in the default PostgreSQL database named `postgres`. The `pg_cron` objects are created in this `postgres` database and all scheduling actions run in this database.
1. You can use the default settings, or you can schedule jobs to run in other databases within your PostgreSQL DB instance. To schedule jobs for other databases within your PostgreSQL DB instance, see the example in [Scheduling a cron job for a database other than the default database](#PostgreSQL_pg_cron.otherDB).
## Granting database users permissions to use pg\$1cron
Installing the `pg_cron` extension requires the `rds_superuser` privileges. However, permissions to use the `pg_cron` can be granted (by a member of the `rds_superuser` group/role) to other database users, so that they can schedule their own jobs. We recommend that you grant permissions to the `cron` schema only as needed if it improves operations in your production environment.
To grant a database user permission in the `cron` schema, run the following command:
```
postgres=> GRANT USAGE ON SCHEMA cron TO db-user;
```
This gives *db-user* permission to access the `cron` schema to schedule cron jobs for the objects that they have permissions to access. If the database user doesn't have permissions, the job fails after posting the error message to the `postgresql.log` file, as shown in the following:
```
2020-12-08 16:41:00 UTC::@:[30647]:ERROR: permission denied for table table-name
2020-12-08 16:41:00 UTC::@:[27071]:LOG: background worker "pg_cron" (PID 30647) exited with exit code 1
```
In other words, make sure that database users that are granted permissions on the `cron` schema also have permissions on the objects (tables, schemas, and so on) that they plan to schedule.
The details of the cron job and its success or failure are also captured in the `cron.job_run_details` table. For more information, see [Tables for scheduling jobs and capturing status](#PostgreSQL_pg_cron.tables).
## Scheduling pg\$1cron jobs
The following sections show how you can schedule various management tasks using `pg_cron` jobs.
**Note**
When you create `pg_cron` jobs, check that the `max_worker_processes` setting is larger than the number of `cron.max_running_jobs`. A `pg_cron` job fails if it runs out of background worker processes. The default number of `pg_cron` jobs is `5`. For more information, see [Parameters for managing the pg\$1cron extension](#PostgreSQL_pg_cron.parameters).
**Topics**
+ [Vacuuming a table](#PostgreSQL_pg_cron.vacuum)
+ [Purging the pg\$1cron history table](#PostgreSQL_pg_cron.job_run_details)
+ [Logging errors to the postgresql.log file only](#PostgreSQL_pg_cron.log_run)
+ [Scheduling a cron job for a database other than the default database](#PostgreSQL_pg_cron.otherDB)
### Vacuuming a table
Autovacuum handles vacuum maintenance for most cases. However, you might want to schedule a vacuum of a specific table at a time of your choosing.
Following is an example of using the `cron.schedule` function to set up a job to use `VACUUM FREEZE` on a specific table every day at 22:00 (GMT).
```
SELECT cron.schedule('manual vacuum', '0 22 * * *', 'VACUUM FREEZE pgbench_accounts');
schedule
----------
1
(1 row)
```
After the preceding example runs, you can check the history in the `cron.job_run_details` table as follows.
```
postgres=> SELECT * FROM cron.job_run_details;
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
-------+-------+---------+----------+----------+--------------------------------+-----------+----------------+-------------------------------+-------------------------------
1 | 1 | 3395 | postgres | adminuser| vacuum freeze pgbench_accounts | succeeded | VACUUM | 2020-12-04 21:10:00.050386+00 | 2020-12-04 21:10:00.072028+00
(1 row)
```
Following is a query of the `cron.job_run_details` table to see the failed jobs.
```
postgres=> SELECT * FROM cron.job_run_details WHERE status = 'failed';
jobid | runid | job_pid | database | username | command | status | return_message | start_time | end_time
------+-------+---------+----------+----------+-------------------------------+--------+--------------------------------------------------+-------------------------------+------------------------------
5 | 4 | 30339 | postgres | adminuser| vacuum freeze pgbench_account | failed | ERROR: relation "pgbench_account" does not exist | 2020-12-04 21:48:00.015145+00 | 2020-12-04 21:48:00.029567+00
(1 row)
```
For more information, see [Tables for scheduling jobs and capturing status](#PostgreSQL_pg_cron.tables).
### Purging the pg\$1cron history table
The `cron.job_run_details` table contains a history of cron jobs that can become very large over time. We recommend that you schedule a job that purges this table. For example, keeping a week's worth of entries might be sufficient for troubleshooting purposes.
The following example uses the [cron.schedule](#PostgreSQL_pg_cron.schedule) function to schedule a job that runs every day at midnight to purge the `cron.job_run_details` table. The job keeps only the last seven days. Use your `rds_superuser` account to schedule the job such as the following.
```
SELECT cron.schedule('0 0 * * *', $$DELETE
FROM cron.job_run_details
WHERE end_time < now() - interval '7 days'$$);
```
For more information, see [Tables for scheduling jobs and capturing status](#PostgreSQL_pg_cron.tables).
### Logging errors to the postgresql.log file only
To prevent writing to the `cron.job_run_details` table, modify the parameter group associated with the PostgreSQL DB instance and set the `cron.log_run` parameter to off. The `pg_cron` extension no longer writes to the table and captures errors to the `postgresql.log` file only. For more information, see [Modifying parameters in a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md).
Use the following command to check the value of the `cron.log_run` parameter.
```
postgres=> SHOW cron.log_run;
```
For more information, see [Parameters for managing the pg\$1cron extension](#PostgreSQL_pg_cron.parameters).
### Scheduling a cron job for a database other than the default database
The metadata for `pg_cron` is all held in the PostgreSQL default database named `postgres`. Because background workers are used for running the maintenance cron jobs, you can schedule a job in any of your databases within the PostgreSQL DB instance:
**Note**
Only users with `rds_superuser` role or `rds_superuser` privileges can list all cron jobs in the database. Other users can view only their own jobs in the `cron.job` table.
1. In the cron database, schedule the job as you normally do using the [cron.schedule](#PostgreSQL_pg_cron.schedule).
```
postgres=> SELECT cron.schedule('database1 manual vacuum', '29 03 * * *', 'vacuum freeze test_table');
```
1. As a user with the `rds_superuser` role, update the database column for the job that you just created so that it runs in another database within your PostgreSQL DB instance.
```
postgres=> UPDATE cron.job SET database = 'database1' WHERE jobid = 106;
```
1. Verify by querying the `cron.job` table.
```
postgres=> SELECT * FROM cron.job;
jobid | schedule | command | nodename | nodeport | database | username | active | jobname
------+-------------+--------------------------------+-----------+----------+----------+-----------+--------+-------------------------
106 | 29 03 * * * | vacuum freeze test_table | localhost | 8192 | database1| adminuser | t | database1 manual vacuum
1 | 59 23 * * * | vacuum freeze pgbench_accounts | localhost | 8192 | postgres | adminuser | t | manual vacuum
(2 rows)
```
**Note**
In some situations, you might add a cron job that you intend to run on a different database. In such cases, the job might try to run in the default database (`postgres`) before you update the correct database column. If the user name has permissions, the job successfully runs in the default database.
## Reference for the pg\$1cron extension
You can use the following parameters, functions, and tables with the `pg_cron` extension. For more information, see [What is pg\$1cron?](https://github.com/citusdata/pg_cron) in the pg\$1cron documentation.
**Topics**
+ [Parameters for managing the pg\$1cron extension](#PostgreSQL_pg_cron.parameters)
+ [Function reference: cron.schedule](#PostgreSQL_pg_cron.schedule)
+ [Function reference: cron.unschedule](#PostgreSQL_pg_cron.unschedule)
+ [Tables for scheduling jobs and capturing status](#PostgreSQL_pg_cron.tables)
### Parameters for managing the pg\$1cron extension
Following is a list of parameters that control the `pg_cron` extension behavior.
| Parameter | Description |
| --- | --- |
| cron.database\$1name | The database in which `pg_cron` metadata is kept. |
| cron.host | The hostname to connect to PostgreSQL. You can't modify this value. |
| cron.log\$1run | Log every job that runs in the `job_run_details` table. Values are `on` or `off`. For more information, see [Tables for scheduling jobs and capturing status](#PostgreSQL_pg_cron.tables). |
| cron.log\$1statement | Log all cron statements before running them. Values are `on` or `off`. |
| cron.max\$1running\$1jobs | The maximum number of jobs that can run concurrently. |
| cron.use\$1background\$1workers | Use background workers instead of client sessions. You can't modify this value. |
Use the following SQL command to display these parameters and their values.
```
postgres=> SELECT name, setting, short_desc FROM pg_settings WHERE name LIKE 'cron.%' ORDER BY name;
```
### Function reference: cron.schedule
This function schedules a cron job. The job is initially scheduled in the default `postgres` database. The function returns a `bigint` value representing the job identifier. To schedule jobs to run in other databases within your PostgreSQL DB instance, see the example in [Scheduling a cron job for a database other than the default database](#PostgreSQL_pg_cron.otherDB).
The function has two syntax formats.
**Syntax**
```
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
**Parameters**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_pg_cron.html)
**Examples**
```
postgres=> SELECT cron.schedule ('test','0 10 * * *', 'VACUUM pgbench_history');
schedule
----------
145
(1 row)
postgres=> SELECT cron.schedule ('0 15 * * *', 'VACUUM pgbench_accounts');
schedule
----------
146
(1 row)
```
### Function reference: cron.unschedule
This function deletes a cron job. You can specify either the `job_name` or the `job_id`. A policy makes sure that you are the owner to remove the schedule for the job. The function returns a Boolean indicating success or failure.
The function has the following syntax formats.
**Syntax**
```
cron.unschedule (job_id);
cron.unschedule (job_name);
```
**Parameters**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/PostgreSQL_pg_cron.html)
**Examples**
```
postgres=> SELECT cron.unschedule(108);
unschedule
------------
t
(1 row)
postgres=> SELECT cron.unschedule('test');
unschedule
------------
t
(1 row)
```
### Tables for scheduling jobs and capturing status
The following tables are used to schedule the cron jobs and record how the jobs completed.
| Table | Description |
| --- | --- |
| cron.job | Contains the metadata about each scheduled job. Most interactions with this table should be done by using the `cron.schedule` and `cron.unschedule` functions. We recommend that you don't give update or insert privileges directly to this table. Doing so would allow the user to update the `username` column to run as `rds-superuser`. |
| cron.job\$1run\$1details | Contains historic information about past scheduled jobs that ran. This is useful to investigate the status, return messages, and start and end time from the job that ran. To prevent this table from growing indefinitely, purge it on a regular basis. For an example, see [Purging the pg\$1cron history table](#PostgreSQL_pg_cron.job_run_details). |
# Using pgAudit to log database activity
Financial institutions, government agencies, and many industries need to keep *audit logs* to meet regulatory requirements. By using the PostgreSQL Audit extension (pgAudit) with your Aurora PostgreSQL DB cluster, you can capture the detailed records that are typically needed by auditors or to meet regulatory requirements. For example, you can set up the pgAudit extension to track changes made to specific databases and tables, to record the user who made the change, and many other details.
The pgAudit extension builds on the functionality of the native PostgreSQL logging infrastructure by extending the log messages with more detail. In other words, you use the same approach to view your audit log as you do to view any log messages. For more information about PostgreSQL logging, see [Aurora PostgreSQL database log files](USER_LogAccess.Concepts.PostgreSQL.md).
The pgAudit extension redacts sensitive data such as cleartext passwords from the logs. If your Aurora PostgreSQL DB cluster is configured to log data manipulation language (DML) statements as detailed in [Turning on query logging for your Aurora PostgreSQL DB cluster ](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md), you can avoid the cleartext password issue by using the PostgreSQL Audit extension.
You can configure auditing on your database instances with a great degree of specificity. You can audit all databases and all users. Or, you can choose to audit only certain databases, users, and other objects. You can also explicitly exclude certain users and databases from being audited. For more information, see [Excluding users or databases from audit logging](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md).
Given the amount of detail that can be captured, we recommend that if you do use pgAudit, you monitor your storage consumption.
The pgAudit extension is supported on all available Aurora PostgreSQL versions. For a list of pgAudit versions supported by Aurora PostgreSQL version, see [Extension versions for Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in the *Release Notes for Aurora PostgreSQL*.
**Topics**
+ [Setting up the pgAudit extension](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md)
+ [Auditing database objects](Appendix.PostgreSQL.CommonDBATasks.pgaudit.auditing.md)
+ [Excluding users or databases from audit logging](Appendix.PostgreSQL.CommonDBATasks.pgaudit.exclude-user-db.md)
+ [Reference for the pgAudit extension](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md)
# Setting up the pgAudit extension
To set up the pgAudit extension on your Aurora PostgreSQL DB cluster, you first add pgAudit to the shared libraries on the custom DB cluster parameter group for your Aurora PostgreSQL DB cluster. For information about creating a custom DB cluster parameter group, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md). Next, you install the pgAudit extension. Finally, you specify the databases and objects that you want to audit. The procedures in this section show you how. You can use the AWS Management Console or the AWS CLI.
You must have permissions as the `rds_superuser` role to perform all these tasks.
The steps following assume that your Aurora PostgreSQL DB cluster is associated with a custom DB cluster parameter group.
## Console
**To set up the pgAudit extension**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose your Aurora PostgreSQL DB cluster's Writer instance .
1. Open the **Configuration** tab for your Aurora PostgreSQL DB cluster writer instance. Among the Instance details, find the **Parameter group** link.
1. Choose the link to open the custom parameters associated with your Aurora PostgreSQL DB cluster.
1. In the **Parameters** search field, type `shared_pre` to find the `shared_preload_libraries` parameter.
1. Choose **Edit parameters** to access the property values.
1. Add `pgaudit` to the list in the **Values** field. Use a comma to separate items in the list of values.
![\[Image of the shared_preload_libaries parameter with pgAudit added.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg_rpg_shared_preload_pgaudit.png)
1. Reboot the writer instance of your Aurora PostgreSQL DB cluster so that your change to the `shared_preload_libraries` parameter takes effect.
1. When the instance is available, verify that pgAudit has been initialized. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster, and then run the following command.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
1. With pgAudit initialized, you can now create the extension. You need to create the extension after initializing the library because the `pgaudit` extension installs event triggers for auditing data definition language (DDL) statements.
```
CREATE EXTENSION pgaudit;
```
1. Close the `psql` session.
```
labdb=> \q
```
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Find the `pgaudit.log` parameter in the list and set to the appropriate value for your use case. For example, setting the `pgaudit.log` parameter to `write` as shown in the following image captures inserts, updates, deletes, and some other types changes to the log.
![\[Image of the pgaudit.log parameter with setting.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/rpg_set_pgaudit-log-level.png)
You can also choose one of the following values for the `pgaudit.log` parameter.
+ none – This is the default. No database changes are logged.
+ all – Logs everything (read, write, function, role, ddl, misc).
+ ddl – Logs all data definition language (DDL) statements that aren't included in the `ROLE` class.
+ function – Logs function calls and `DO` blocks.
+ misc – Logs miscellaneous commands, such as `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM`, and `SET`.
+ read – Logs `SELECT` and `COPY` when the source is a relation (such as a table) or a query.
+ role – Logs statements related to roles and privileges, such as `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE`, and `DROP ROLE`.
+ write – Logs `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, and `COPY` when the destination is a relation (table).
1. Choose **Save changes**.
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choose your Aurora PostgreSQL DB cluster's writer instance from the Databases list.
## AWS CLI
**To setup pgAudit**
To setup pgAudit using the AWS CLI, you call the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) operation to modify the audit log parameters in your custom parameter group, as shown in the following procedure.
1. Use the following AWS CLI command to add `pgaudit` to the `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use the following AWS CLI command to reboot the writer instance of your Aurora PostgreSQL DB cluster so that the pgaudit library is initialized.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. When the instance is available, you can verify that `pgaudit` has been initialized. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster, and then run the following command.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pgaudit
(1 row)
```
With pgAudit initialized, you can now create the extension.
```
CREATE EXTENSION pgaudit;
```
1. Close the `psql` session so that you can use the AWS CLI.
```
labdb=> \q
```
1. Use the following AWS CLI command to specify the classes of statement that want logged by session audit logging. The example sets the `pgaudit.log` parameter to `write`, which captures inserts, updates, and deletes to the log.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.log,ParameterValue=write,ApplyMethod=pending-reboot" \
--region aws-region
```
You can also choose one of the following values for the `pgaudit.log` parameter.
+ none – This is the default. No database changes are logged.
+ all – Logs everything (read, write, function, role, ddl, misc).
+ ddl – Logs all data definition language (DDL) statements that aren't included in the `ROLE` class.
+ function – Logs function calls and `DO` blocks.
+ misc – Logs miscellaneous commands, such as `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM`, and `SET`.
+ read – Logs `SELECT` and `COPY` when the source is a relation (such as a table) or a query.
+ role – Logs statements related to roles and privileges, such as `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE`, and `DROP ROLE`.
+ write – Logs `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, and `COPY` when the destination is a relation (table).
Reboot the writer instance of your Aurora PostgreSQL DB cluster using the following AWS CLI command.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
# Auditing database objects
With pgAudit set up on your Aurora PostgreSQL DB cluster and configured for your requirements, more detailed information is captured in the PostgreSQL log. For example, while the default PostgreSQL logging configuration identifies the date and time that a change was made in a database table, with the pgAudit extension the log entry can include the schema, user who made the change, and other details depending on how the extension parameters are configured. You can set up auditing to track changes in the following ways.
+ For each session, by user. For the session level, you can capture the fully qualified command text.
+ For each object, by user and by database.
The object auditing capability is activated when you create the `rds_pgaudit` role on your system and then add this role to the `pgaudit.role` parameter in your custom parameter parameter group. By default, the `pgaudit.role` parameter is unset and the only allowable value is `rds_pgaudit`. The following steps assume that `pgaudit` has been initialized and that you have created the `pgaudit` extension by following the procedure in [Setting up the pgAudit extension](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md).
![\[Image of the PostgreSQL log file after setting up pgAudit.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/pgaudit-log-example.png)
As shown in this example, the "LOG: AUDIT: SESSION" line provides information about the table and its schema, among other details.
**To set up object auditing**
1. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=your-instance-name.aws-region.rds.amazonaws.com --port=5432 --username=postgrespostgres --password --dbname=labdb
```
1. Create a database role named `rds_pgaudit` using the following command.
```
labdb=> CREATE ROLE rds_pgaudit;
CREATE ROLE
labdb=>
```
1. Close the `psql` session.
```
labdb=> \q
```
In the next few steps, use the AWS CLI to modify the audit log parameters in your custom parameter group.
1. Use the following AWS CLI command to set the `pgaudit.role` parameter to `rds_pgaudit`. By default, this parameter is empty, and `rds_pgaudit` is the only allowable value.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=pgaudit.role,ParameterValue=rds_pgaudit,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use the following AWS CLI command to reboot the writer instance of your Aurora PostgreSQL DB cluster so that your changes to the parameters take effect.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. Run the following command to confirm that the `pgaudit.role` is set to `rds_pgaudit`.
```
SHOW pgaudit.role;
pgaudit.role
------------------
rds_pgaudit
```
To test pgAudit logging, you can run several example commands that you want to audit. For example, you might run the following commands.
```
CREATE TABLE t1 (id int);
GRANT SELECT ON t1 TO rds_pgaudit;
SELECT * FROM t1;
id
----
(0 rows)
```
The database logs should contain an entry similar to the following.
```
...
2017-06-12 19:09:49 UTC:...:rds_test@postgres:[11701]:LOG: AUDIT:
OBJECT,1,1,READ,SELECT,TABLE,public.t1,select * from t1;
...
```
For information on viewing the logs, see [Monitoring Amazon Aurora log files](USER_LogAccess.md).
To learn more about the pgAudit extension, see [pgAudit](https://github.com/pgaudit/pgaudit/blob/master/README.md) on GitHub.
# Excluding users or databases from audit logging
As discussed in [Aurora PostgreSQL database log files](USER_LogAccess.Concepts.PostgreSQL.md), PostgreSQL logs consume storage space. Using the pgAudit extension adds to the volume of data gathered in your logs to varying degrees, depending on the changes that you track. You might not need to audit every user or database in your Aurora PostgreSQL DB cluster.
To minimize impacts to your storage and to avoid needlessly capturing audit records, you can exclude users and databases from being audited. You can also change logging within a given session. The following examples show you how.
**Note**
Parameter settings at the session level take precedence over the settings in the custom DB cluster parameter group for the Aurora PostgreSQL DB cluster's writer instance. If you don't want database users to bypass your audit logging configuration settings, be sure to change their permissions.
Suppose that your Aurora PostgreSQL DB cluster is configured to audit the same level of activity for all users and databases. You then decide that you don't want to audit the user `myuser`. You can turn off auditing for `myuser` with the following SQL command.
```
ALTER USER myuser SET pgaudit.log TO 'NONE';
```
Then, you can use the following query to check the `user_specific_settings` column for `pgaudit.log` to confirm that the parameter is set to `NONE`.
```
SELECT
usename AS user_name,
useconfig AS user_specific_settings
FROM
pg_user
WHERE
usename = 'myuser';
```
You see output such as the following.
```
user_name | user_specific_settings
-----------+------------------------
myuser | {pgaudit.log=NONE}
(1 row)
```
You can turn off logging for a given user in the midst of their session with the database with the following command.
```
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'none';
```
Use the following query to check the settings column for pgaudit.log for a specific user and database combination.
```
SELECT
usename AS "user_name",
datname AS "database_name",
pg_catalog.array_to_string(setconfig, E'\n') AS "settings"
FROM
pg_catalog.pg_db_role_setting s
LEFT JOIN pg_catalog.pg_database d ON d.oid = setdatabase
LEFT JOIN pg_catalog.pg_user r ON r.usesysid = setrole
WHERE
usename = 'myuser'
AND datname = 'mydatabase'
ORDER BY
1,
2;
```
You see output similar to the following.
```
user_name | database_name | settings
-----------+---------------+------------------
myuser | mydatabase | pgaudit.log=none
(1 row)
```
After turning off auditing for `myuser`, you decide that you don't want to track changes to `mydatabase`. You turn off auditing for that specific database by using the following command.
```
ALTER DATABASE mydatabase SET pgaudit.log to 'NONE';
```
Then, use the following query to check the database\$1specific\$1settings column to confirm that pgaudit.log is set to NONE.
```
SELECT
a.datname AS database_name,
b.setconfig AS database_specific_settings
FROM
pg_database a
FULL JOIN pg_db_role_setting b ON a.oid = b.setdatabase
WHERE
a.datname = 'mydatabase';
```
You see output such as the following.
```
database_name | database_specific_settings
---------------+----------------------------
mydatabase | {pgaudit.log=NONE}
(1 row)
```
To return settings to the default setting for myuser, use the following command:
```
ALTER USER myuser RESET pgaudit.log;
```
To return settings to their default setting for a database, use the following command.
```
ALTER DATABASE mydatabase RESET pgaudit.log;
```
To reset user and database to the default setting, use the following command.
```
ALTER USER myuser IN DATABASE mydatabase RESET pgaudit.log;
```
You can also capture specific events to the log by setting the `pgaudit.log` to one of the other allowed values for the `pgaudit.log` parameter. For more information, see [List of allowable settings for the `pgaudit.log` parameter](Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.md#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings).
```
ALTER USER myuser SET pgaudit.log TO 'read';
ALTER DATABASE mydatabase SET pgaudit.log TO 'function';
ALTER USER myuser IN DATABASE mydatabase SET pgaudit.log TO 'read,function'
```
# Reference for the pgAudit extension
You can specify the level of detail that you want for your audit log by changing one or more of the parameters listed in this section.
## Controlling pgAudit behavior
You can control the audit logging by changing one or more of the parameters listed in the following table.
| Parameter | Description |
| --- | --- |
| `pgaudit.log` | Specifies the statement classes that will be logged by session audit logging. Allowable values include ddl, function, misc, read, role, write, none, all. For more information, see [List of allowable settings for the `pgaudit.log` parameter](#Appendix.PostgreSQL.CommonDBATasks.pgaudit.reference.pgaudit-log-settings). |
| `pgaudit.log_catalog` | When turned on (set to 1), adds statements to audit trail if all relations in a statement are in pg\$1catalog. |
| `pgaudit.log_level` | Specifies the log level to use for log entries. Allowed values: debug5, debug4, debug3, debug2, debug1, info, notice, warning, log |
| `pgaudit.log_parameter` | When turned on (set to 1), parameters passed with the statement are captured in the audit log. |
| `pgaudit.log_relation` | When turned on (set to 1), the audit log for the session creates a separate log entry for each relation (TABLE, VIEW, and so on) referenced in a SELECT or DML statement. |
| `pgaudit.log_statement_once` | Specifies whether logging will include the statement text and parameters with the first log entry for a statement/substatement combination or with every entry. |
| `pgaudit.role` | Specifies the master role to use for object audit logging. The only allowable entry is `rds_pgaudit`. |
## List of allowable settings for the `pgaudit.log` parameter
| Value | Description |
| --- | --- |
| none | This is the default. No database changes are logged. |
| all | Logs everything (read, write, function, role, ddl, misc). |
| ddl | Logs all data definition language (DDL) statements that aren't included in the `ROLE` class. |
| function | Logs function calls and `DO` blocks. |
| misc | Logs miscellaneous commands, such as `DISCARD`, `FETCH`, `CHECKPOINT`, `VACUUM`, and `SET`. |
| read | Logs `SELECT` and `COPY` when the source is a relation (such as a table) or a query. |
| role | Logs statements related to roles and privileges, such as `GRANT`, `REVOKE`, `CREATE ROLE`, `ALTER ROLE`, and `DROP ROLE`. |
| write | Logs `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, and `COPY` when the destination is a relation (table). |
To log multiple event types with session auditing, use a comma-separated list. To log all event types, set `pgaudit.log` to `ALL`. Reboot your DB instance to apply the changes.
With object auditing, you can refine audit logging to work with specific relations. For example, you can specify that you want audit logging for `READ` operations on one or more tables.
# Using pglogical to synchronize data across instances
All currently available Aurora PostgreSQL versions support the `pglogical` extension. The pglogical extension predates the functionally similar logical replication feature that was introduced by PostgreSQL in version 10. For more information, see [Overview of PostgreSQL logical replication with Aurora](AuroraPostgreSQL.Replication.Logical.md).
The `pglogical` extension supports logical replication between two or more Aurora PostgreSQL DB clusters. It also supports replication between different PostgreSQL versions, and between databases running on RDS for PostgreSQL DB instances and Aurora PostgreSQL DB clusters. The `pglogical` extension uses a publish-subscribe model to replicate changes to tables and other objects, such as sequences, from a publisher to a subscriber. It relies on a replication slot to ensure that changes are synchronized from a publisher node to a subscriber node, defined as follows.
+ The *publisher node* is the Aurora PostgreSQL DB cluster that's the source of data to be replicated to other nodes. The publisher node defines the tables to be replicated in a publication set.
+ The *subscriber node* is the Aurora PostgreSQL DB cluster that receives WAL updates from the publisher. The subscriber creates a subscription to connect to the publisher and get the decoded WAL data. When the subscriber creates the subscription, the replication slot is created on the publisher node.
Following, you can find information about setting up the `pglogical` extension.
**Topics**
+ [Requirements and limitations for the pglogical extension](#Appendix.PostgreSQL.CommonDBATasks.pglogical.requirements-limitations)
+ [Setting up the pglogical extension](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md)
+ [Setting up logical replication for Aurora PostgreSQL DB cluster](Appendix.PostgreSQL.CommonDBATasks.pglogical.setup-replication.md)
+ [Reestablishing logical replication after a major upgrade](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)
+ [Managing logical replication slots for Aurora PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.pglogical.handle-slots.md)
+ [Parameter reference for the pglogical extension](Appendix.PostgreSQL.CommonDBATasks.pglogical.reference.md)
## Requirements and limitations for the pglogical extension
All currently available releases of Aurora PostgreSQL support the `pglogical` extension.
Both the publisher node and the subscriber node must be set up for logical replication.
The tables that you want to replicate from a publisher to a subscriber must have the same names and the same schema. These tables must also contain the same columns, and the columns must use the same data types. Both publisher and subscriber tables must have the same primary keys. We recommend that you use only the PRIMARY KEY as the unique constraint.
The tables on the subscriber node can have more permissive constraints than those on the publisher node for CHECK constraints and NOT NULL constraints.
The `pglogical` extension provides features such as two-way replication that aren't supported by the logical replication feature built into PostgreSQL (version 10 and higher). For more information, see [PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
# Setting up the pglogical extension
To set up the `pglogical` extension on your Aurora PostgreSQL DB cluster, you add `pglogical` to the shared libraries on the custom DB cluster parameter group for your Aurora PostgreSQL DB cluster. You also need to set the value of the `rds.logical_replication` parameter to `1`, to turn on logical decoding. Finally, you create the extension in the database. You can use the AWS Management Console or the AWS CLI for these tasks.
You must have permissions as the `rds_superuser` role to perform these tasks.
The steps following assume that your Aurora PostgreSQL DB cluster is associated with a custom DB cluster parameter group. For information about creating a custom DB cluster parameter group, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).
## Console
**To set up the pglogical extension**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose your Aurora PostgreSQL DB cluster's Writer instance .
1. Open the **Configuration** tab for your Aurora PostgreSQL DB cluster writer instance. Among the Instance details, find the **Parameter group** link.
1. Choose the link to open the custom parameters associated with your Aurora PostgreSQL DB cluster.
1. In the **Parameters** search field, type `shared_pre` to find the `shared_preload_libraries` parameter.
1. Choose **Edit parameters** to access the property values.
1. Add `pglogical` to the list in the **Values** field. Use a comma to separate items in the list of values.
![\[Image of the shared_preload_libraries parameter with pglogical added.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg_rpg_shared_preload_pglogical.png)
1. Find the `rds.logical_replication` parameter and set it to `1`, to turn on logical replication.
1. Reboot the writer instance of your Aurora PostgreSQL DB cluster so that your changes take effect.
1. When the instance is available, you can use `psql` (or pgAdmin) to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. To verify that pglogical is initialized, run the following command.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pglogical
(1 row)
```
1. Verify the setting that enables logical decoding, as follows.
```
SHOW wal_level;
wal_level
-----------
logical
(1 row)
```
1. Create the extension, as follows.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Choose **Save changes**.
1. Open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choose your Aurora PostgreSQL DB cluster's writer instance from the Databases list to select it, and then choose **Reboot** from the Actions menu.
## AWS CLI
**To setup the pglogical extension**
To setup pglogical using the AWS CLI, you call the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) operation to modify certain parameters in your custom parameter group as shown in the following procedure.
1. Use the following AWS CLI command to add `pglogical` to the `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pglogical,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use the following AWS CLI command to set `rds.logical_replication` to `1` to turn on the logical decoding capability for the writer instance of the Aurora PostgreSQL DB cluster.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use the following AWS CLI command to reboot the writer instance of your Aurora PostgreSQL DB cluster so that the pglogical library is initialized.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. When the instance is available, use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Create the extension, as follows.
```
CREATE EXTENSION pglogical;
EXTENSION CREATED
```
1. Reboot the writer instance of your Aurora PostgreSQL DB cluster using the following AWS CLI command.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
# Setting up logical replication for Aurora PostgreSQL DB cluster
The following procedure shows you how to start logical replication between two Aurora PostgreSQL DB clusters. The steps assume that both the source (publisher) and the target (subscriber) have the `pglogical` extension set up as detailed in [Setting up the pglogical extension](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
**Note**
The `node_name` of a subscriber node can't start with `rds`.
**To create the publisher node and define the tables to replicate**
These steps assume that your Aurora PostgreSQL DB cluster has a writer instance with a database that has one or more tables that you want to replicate to another node. You need to recreate the table structure from the publisher on the subscriber, so first, get the table structure if necessary. You can do that by using the `psql` metacommand `\d tablename` and then creating the same table on the subscriber instance. The following procedure creates an example table on the publisher (source) for demonstration purposes.
1. Use `psql` to connect to the instance that has the table you want to use as a source for subscribers.
```
psql --host=source-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
If you don't have an existing table that you want to replicate, you can create a sample table as follows.
1. Create an example table using the following SQL statement.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Populate the table with generated data by using the following SQL statement.
```
INSERT INTO docs_lab_table VALUES (generate_series(1,5000));
INSERT 0 5000
```
1. Verify that data exists in the table by using the following SQL statement.
```
SELECT count(*) FROM docs_lab_table;
```
1. Identify this Aurora PostgreSQL DB cluster as the publisher node, as follows.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_provider',
dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 dbname=labdb');
create_node
-------------
3410995529
(1 row)
```
1. Add the table that you want to replicate to the default replication set. For more information about replication sets, see [Replication sets](https://github.com/2ndQuadrant/pglogical/tree/REL2_x_STABLE/docs#replication-sets) in the pglogical documentation.
```
SELECT pglogical.replication_set_add_table('default', 'docs_lab_table', 'true', NULL, NULL);
replication_set_add_table
---------------------------
t
(1 row)
```
The publisher node setup is complete. You can now set up the subscriber node to receive the updates from the publisher.
**To set up the subscriber node and create a subscription to receive updates**
These steps assume that the Aurora PostgreSQL DB cluster has been set up with the `pglogical` extension. For more information, see [Setting up the pglogical extension](Appendix.PostgreSQL.CommonDBATasks.pglogical.basic-setup.md).
1. Use `psql` to connect to the instance that you want to receive updates from the publisher.
```
psql --host=target-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. On the subscriber Aurora PostgreSQL DB cluster, ,create the same table that exists on the publisher. For this example, the table is `docs_lab_table`. You can create the table as follows.
```
CREATE TABLE docs_lab_table (a int PRIMARY KEY);
```
1. Verify that this table is empty.
```
SELECT count(*) FROM docs_lab_table;
count
-------
0
(1 row)
```
1. Identify this Aurora PostgreSQL DB cluster as the subscriber node, as follows.
```
SELECT pglogical.create_node(
node_name := 'docs_lab_target',
dsn := 'host=target-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=********');
create_node
-------------
2182738256
(1 row)
```
1. Create the subscription.
```
SELECT pglogical.create_subscription(
subscription_name := 'docs_lab_subscription',
provider_dsn := 'host=source-instance.aws-region.rds.amazonaws.com port=5432 sslmode=require dbname=labdb user=postgres password=*******',
replication_sets := ARRAY['default'],
synchronize_data := true,
forward_origins := '{}' );
create_subscription
---------------------
1038357190
(1 row)
```
When you complete this step, the data from the table on the publisher is created in the table on the subscriber. You can verify that this has occurred by using the following SQL query.
```
SELECT count(*) FROM docs_lab_table;
count
-------
5000
(1 row)
```
From this point forward, changes made to the table on the publisher are replicated to the table on the subscriber.
# Reestablishing logical replication after a major upgrade
Before you can perform a major version upgrade of an Aurora PostgreSQL DB cluster that's set up as a publisher node for logical replication, you must drop all replication slots, even those that aren't active. We recommend that you temporarily divert database transactions from the publisher node, drop the replication slots, upgrade the Aurora PostgreSQL DB cluster, and then re-establish and restart replication.
The replication slots are hosted on the publisher node only. The Aurora PostgreSQL subscriber node in a logical replication scenario has no slots to drop. The Aurora PostgreSQL major version upgrade process supports upgrading the subscriber to a new major version of PostgreSQL independent of the publisher node. However, the upgrade process does disrupt the replication process and interferes with the synchronization of WAL data between publisher node and subscriber node. You need to re-establish logical replication between publisher and subscriber after upgrading the publisher, the subscriber, or both. The following procedure shows you how to determine that replication has been disrupted and how to resolve the issue.
## Determining that logical replication has been disrupted
You can determine that the replication process has been disrupted by querying either the publisher node or the subscriber node, as follows.
**To check the publisher node**
+ Use `psql` to connect to the publisher node, and then query the `pg_replication_slots` function. Note the value in the active column. Normally, this will return `t` (true), showing that replication is active. If the query returns `f` (false), it's an indication that replication to the subscriber has stopped.
```
SELECT slot_name,plugin,slot_type,active FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_labcb4fa94_docs_lab3de412c | pglogical_output | logical | f
(1 row)
```
**To check the subscriber node**
On the subscriber node, you can check the status of replication in three different ways.
+ Look through the PostgreSQL logs on the subscriber node to find failure messages. The log identifies failure with messages that include exit code 1, as shown following.
```
2022-07-06 16:17:03 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 14610) exited with exit code 1
2022-07-06 16:19:44 UTC::@:[7361]:LOG: background worker "pglogical apply 16404:2880255011" (PID 21783) exited with exit code 1
```
+ Query the `pg_replication_origin` function. Connect to the database on the subscriber node using `psql` and query the `pg_replication_origin` function, as follows.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+--------
(0 rows)
```
The empty result set means that replication has been disrupted. Normally, you see output such as the following.
```
roident | roname
---------+----------------------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
+ Query the `pglogical.show_subscription_status` function as shown in the following example.
```
SELECT subscription_name,status,slot_name FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
---====----------------+--------+-------------------------------------
docs_lab_subscription | down | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
This output shows that replication has been disrupted. Its status is `down`. Normally, the output shows the status as `replicating`.
If your logical replication process has been disrupted, you can re-establish replication by following these steps.
**To reestablish logical replication between publisher and subscriber nodes**
To re-establish replication, you first disconnect the subscriber from the publisher node and then re-establish the subscription, as outlined in these steps.
1. Connect to the subscriber node using `psql` as follows.
```
psql --host=222222222222.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
```
1. Deactivate the subscription by using the `pglogical.alter_subscription_disable` function.
```
SELECT pglogical.alter_subscription_disable('docs_lab_subscription',true);
alter_subscription_disable
----------------------------
t
(1 row)
```
1. Get the publisher node's identifier by querying the `pg_replication_origin`, as follows.
```
SELECT * FROM pg_replication_origin;
roident | roname
---------+-------------------------------------
1 | pgl_labdb_docs_labcb4fa94_docs_lab3de412c
(1 row)
```
1. Use the response from the previous step with the `pg_replication_origin_create` command to assign the identifier that can be used by the subscription when re-established.
```
SELECT pg_replication_origin_create('pgl_labdb_docs_labcb4fa94_docs_lab3de412c');
pg_replication_origin_create
------------------------------
1
(1 row)
```
1. Turn on the subscription by passing its name with a status of `true`, as shown in the following example.
```
SELECT pglogical.alter_subscription_enable('docs_lab_subscription',true);
alter_subscription_enable
---------------------------
t
(1 row)
```
Check the status of the node. Its status should be `replicating` as shown in this example.
```
SELECT subscription_name,status,slot_name
FROM pglogical.show_subscription_status();
subscription_name | status | slot_name
-------------------------------+-------------+-------------------------------------
docs_lab_subscription | replicating | pgl_labdb_docs_lab98f517b_docs_lab3de412c
(1 row)
```
Check the status of the subscriber's replication slot on the publisher node. The slot's `active` column should return `t` (true), indicating that replication has been re-established.
```
SELECT slot_name,plugin,slot_type,active
FROM pg_replication_slots;
slot_name | plugin | slot_type | active
-------------------------------------------+------------------+-----------+--------
pgl_labdb_docs_lab98f517b_docs_lab3de412c | pglogical_output | logical | t
(1 row)
```
# Managing logical replication slots for Aurora PostgreSQL
Before you can perform a major version upgrade on an Aurora PostgreSQL DB cluster's writer instance that's serving as a publisher node in a logical replication scenario, you must drop the replication slots on the instance. The major version upgrade pre-check process notifies you that the upgrade can't proceed until the slots are dropped.
To identify replication slots that were created using the `pglogical` extension, log in to each database and get the name of the nodes. When you query the subscriber node, you get both the publisher and the subscriber nodes in the output, as shown in this example.
```
SELECT * FROM pglogical.node;
node_id | node_name
------------+-------------------
2182738256 | docs_lab_target
3410995529 | docs_lab_provider
(2 rows)
```
You can get the details about the subscription with the following query.
```
SELECT sub_name,sub_slot_name,sub_target
FROM pglogical.subscription;
sub_name | sub_slot_name | sub_target
----------+--------------------------------+------------
docs_lab_subscription | pgl_labdb_docs_labcb4fa94_docs_lab3de412c | 2182738256
(1 row)
```
You can now drop the subscription, as follows.
```
SELECT pglogical.drop_subscription(subscription_name := 'docs_lab_subscription');
drop_subscription
-------------------
1
(1 row)
```
After dropping the subscription, you can delete the node.
```
SELECT pglogical.drop_node(node_name := 'docs-lab-subscriber');
drop_node
-----------
t
(1 row)
```
You can verify that the node no longer exists, as follows.
```
SELECT * FROM pglogical.node;
node_id | node_name
---------+-----------
(0 rows)
```
# Parameter reference for the pglogical extension
In the table you can find parameters associated with the `pglogical` extension. Parameters such as `pglogical.conflict_log_level` and `pglogical.conflict_resolution` are used to handle update conflicts. Conflicts can emerge when changes are made locally to the same tables that are subscribed to changes from the publisher. Conflicts can also occur during various scenarios, such as two-way replication or when multiple subscribers are replicating from the same publisher. For more information, see [ PostgreSQL bi-directional replication using pglogical](https://aws.amazon.com/blogs/database/postgresql-bi-directional-replication-using-pglogical/).
| Parameter | Description |
| --- | --- |
| pglogical.batch\$1inserts | Batch inserts if possible. Not set by default. Change to '1' to turn on, '0' to turn off. |
| pglogical.conflict\$1log\$1level | Sets the log level to use for logging resolved conflicts. Supported string values are debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. |
| pglogical.conflict\$1resolution | Sets method to use to resolve conflicts when conflicts are resolvable. Supported string values are error, apply\$1remote, keep\$1local, last\$1update\$1wins, first\$1update\$1wins. |
| pglogical.extra\$1connection\$1options | Connection options to add to all peer node connections. |
| pglogical.synchronous\$1commit | pglogical specific synchronous commit value |
| pglogical.use\$1spi | Use SPI (server programming interface) instead of low-level API to apply changes. Set to '1' to turn on, '0' to turn off. For more information about SPI, see [Server Programming Interface](https://www.postgresql.org/docs/current/spi.html) in the PostgreSQL documentation. |
# Working with the supported foreign data wrappers for Amazon Aurora PostgreSQL
A foreign data wrapper (FDW) is a specific type of extension that provides access to external data. For example, the `oracle_fdw` extension allows your Aurora PostgreSQL DB instance to work with Oracle databases.
Following, you can find information about several supported PostgreSQL foreign data wrappers.
**Topics**
+ [Using the log\$1fdw extension to access the DB log using SQL](CHAP_PostgreSQL.Extensions.log_fdw.md)
+ [Using the postgres\$1fdw extension to access external data](postgresql-commondbatasks-fdw.md)
+ [Working with MySQL databases by using the mysql\$1fdw extension](postgresql-mysql-fdw.md)
+ [Working with Oracle databases by using the oracle\$1fdw extension](postgresql-oracle-fdw.md)
+ [Working with SQL Server databases by using the tds\$1fdw extension](postgresql-tds-fdw.md)
# Using the log\$1fdw extension to access the DB log using SQL
Aurora PostgreSQL DB cluster supports the `log_fdw` extension, which you can use to access your database engine log using a SQL interface. The `log_fdw` extension provides two functions that make it easy to create foreign tables for database logs:
+ `list_postgres_log_files` – Lists the files in the database log directory and the file size in bytes.
+ `create_foreign_table_for_log_file(table_name text, server_name text, log_file_name text)` – Builds a foreign table for the specified file in the current database.
All functions created by `log_fdw` are owned by `rds_superuser`. Members of the `rds_superuser` role can grant access to these functions to other database users.
By default, the log files are generated by Amazon Aurora in `stderr` (standard error) format, as specified in `log_destination` parameter. There are only two options for this parameter, `stderr` and `csvlog` (comma-separated values, CSV). If you add the `csvlog` option to the parameter, Amazon Aurora generates both `stderr` and `csvlog` logs. This can affect the storage capacity on your DB cluster, so you need to be aware of the other parameters that affect log handling. For more information, see [Setting the log destination (`stderr`, `csvlog`)](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md#USER_LogAccess.Concepts.PostgreSQL.Log_Format).
One benefit of generating `csvlog` logs is that the `log_fdw` extension lets you build foreign tables with the data neatly split into several columns. To do this, your instance needs to be associated with a custom DB parameter group so that you can change the setting for `log_destination`. For more information about how to do so, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).
The following example assumes that the `log_destination` parameter includes `cvslog`.
**To use the log\$1fdw extension**
1. Install the `log_fdw` extension.
```
postgres=> CREATE EXTENSION log_fdw;
CREATE EXTENSION
```
1. Create the log server as a foreign data wrapper.
```
postgres=> CREATE SERVER log_server FOREIGN DATA WRAPPER log_fdw;
CREATE SERVER
```
1. Select all from a list of log files.
```
postgres=> SELECT * FROM list_postgres_log_files() ORDER BY 1;
```
A sample response is as follows.
```
file_name | file_size_bytes
------------------------------+-----------------
postgresql.log.2023-08-09-22.csv | 1111
postgresql.log.2023-08-09-23.csv | 1172
postgresql.log.2023-08-10-00.csv | 1744
postgresql.log.2023-08-10-01.csv | 1102
(4 rows)
```
1. Create a table with a single 'log\$1entry' column for the selected file.
```
postgres=> SELECT create_foreign_table_for_log_file('my_postgres_error_log',
'log_server', 'postgresql.log.2023-08-09-22.csv');
```
The response provides no detail other than that the table now exists.
```
-----------------------------------
(1 row)
```
1. Select a sample of the log file. The following code retrieves the log time and error message description.
```
postgres=> SELECT log_time, message FROM my_postgres_error_log ORDER BY 1;
```
A sample response is as follows.
```
log_time | message
----------------------------------+---------------------------------------------------------------------------
Tue Aug 09 15:45:18.172 2023 PDT | ending log output to stderr
Tue Aug 09 15:45:18.175 2023 PDT | database system was interrupted; last known up at 2023-08-09 22:43:34 UTC
Tue Aug 09 15:45:18.223 2023 PDT | checkpoint record is at 0/90002E0
Tue Aug 09 15:45:18.223 2023 PDT | redo record is at 0/90002A8; shutdown FALSE
Tue Aug 09 15:45:18.223 2023 PDT | next transaction ID: 0/1879; next OID: 24578
Tue Aug 09 15:45:18.223 2023 PDT | next MultiXactId: 1; next MultiXactOffset: 0
Tue Aug 09 15:45:18.223 2023 PDT | oldest unfrozen transaction ID: 1822, in database 1
(7 rows)
```
# Using the postgres\$1fdw extension to access external data
You can access data in a table on a remote database server with the [postgres\$1fdw](https://www.postgresql.org/docs/current/static/postgres-fdw.html) extension. If you set up a remote connection from your PostgreSQL DB instance, access is also available to your read replica.
**To use postgres\$1fdw to access a remote database server**
1. Install the postgres\$1fdw extension.
```
CREATE EXTENSION postgres_fdw;
```
1. Create a foreign data server using CREATE SERVER.
```
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'xxx.xx.xxx.xx', port '5432', dbname 'foreign_db');
```
1. Create a user mapping to identify the role to be used on the remote server.
**Important**
To redact the password so that it doesn't appear in the logs, set `log_statement=none` at the session level. Setting at the parameter level doesn't redact the password.
```
CREATE USER MAPPING FOR local_user
SERVER foreign_server
OPTIONS (user 'foreign_user', password 'password');
```
1. Create a table that maps to the table on the remote server.
```
CREATE FOREIGN TABLE foreign_table (
id integer NOT NULL,
data text)
SERVER foreign_server
OPTIONS (schema_name 'some_schema', table_name 'some_table');
```
# Working with MySQL databases by using the mysql\$1fdw extension
To access a MySQL-compatible database from your Aurora PostgreSQL DB cluster, you can install and use the `mysql_fdw` extension. This foreign data wrapper lets you work with RDS for MySQL, Aurora MySQL, MariaDB, and other MySQL-compatible databases. The connection from Aurora PostgreSQL DB cluster to the MySQL database is encrypted on a best-effort basis, depending on the client and server configurations. However, you can enforce encryption if you like. For more information, see [Using encryption in transit with the extension](#postgresql-mysql-fdw.encryption-in-transit).
The `mysql_fdw` extension is supported on Amazon Aurora PostgreSQL version 15.4, 14.9, 13.12, 12.16, and higher releases. It supports selects, inserts, updates, and deletes from an RDS for PostgreSQL DB to tables on a MySQL-compatible database instance.
**Topics**
+ [Setting up your Aurora PostgreSQL DB to use the mysql\$1fdw extension](#postgresql-mysql-fdw.setting-up)
+ [Example: Working with an Aurora MySQL database from Aurora PostgreSQL](#postgresql-mysql-fdw.using-mysql_fdw)
+ [Using encryption in transit with the extension](#postgresql-mysql-fdw.encryption-in-transit)
## Setting up your Aurora PostgreSQL DB to use the mysql\$1fdw extension
Setting up the `mysql_fdw` extension on your Aurora PostgreSQL DB cluster involves loading the extension in your DB cluster and then creating the connection point to the MySQL DB instance. For that task, you need to have the following details about the MySQL DB instance:
+ Hostname or endpoint. For an Aurora MySQL DB cluster, you can find the endpoint by using the Console. Choose the Connectivity & security tab and look in the "Endpoint and port" section.
+ Port number. The default port number for MySQL is 3306.
+ Name of the database. The DB identifier.
You also need to provide access on the security group or the access control list (ACL) for the MySQL port, 3306. Both the Aurora PostgreSQL DB cluster and the Aurora MySQL DB cluster need access to port 3306. If access isn't configured correctly, when you try to connect to MySQL-compatible table you see an error message similar to the following:
```
ERROR: failed to connect to MySQL: Can't connect to MySQL server on 'hostname.aws-region.rds.amazonaws.com:3306' (110)
```
In the following procedure, you (as the `rds_superuser` account) create the foreign server. You then grant access to the foreign server to specific users. These users then create their own mappings to the appropriate MySQL user accounts to work with the MySQL DB instance.
**To use mysql\$1fdw to access a MySQL database server**
1. Connect to your PostgreSQL DB instance using an account that has the `rds_superuser` role. If you accepted the defaults when you created your Aurora PostgreSQL DB cluster , the user name is `postgres`, and you can connect using the `psql` command line tool as follows:
```
psql --host=your-DB-instance.aws-region.rds.amazonaws.com --port=5432 --username=postgres –-password
```
1. Install the `mysql_fdw` extension as follows:
```
postgres=> CREATE EXTENSION mysql_fdw;
CREATE EXTENSION
```
After the extension is installed on your Aurora PostgreSQL DB cluster , you set up the foreign server that provides the connection to a MySQL database.
**To create the foreign server**
Perform these tasks on the Aurora PostgreSQL DB cluster . The steps assume that you're connected as a user with `rds_superuser` privileges, such as `postgres`.
1. Create a foreign server in the Aurora PostgreSQL DB cluster :
```
postgres=> CREATE SERVER mysql-db FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'db-name.111122223333.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Grant the appropriate users access to the foreign server. These should be non-administrator users, that is, users without the `rds_superuser` role.
```
postgres=> GRANT USAGE ON FOREIGN SERVER mysql-db to user1;
GRANT
```
PostgreSQL users create and manage their own connections to the MySQL database through the foreign server.
## Example: Working with an Aurora MySQL database from Aurora PostgreSQL
Suppose that you have a simple table on an Aurora PostgreSQL DB instance . Your Aurora PostgreSQL users want to query (`SELECT`), `INSERT`, `UPDATE`, and `DELETE` items on that table. Assume that the `mysql_fdw` extension was created on your RDS for PostgreSQL DB instance, as detailed in the preceding procedure. After you connect to the RDS for PostgreSQL DB instance as a user that has `rds_superuser` privileges, you can proceed with the following steps.
1. On the Aurora PostgreSQL DB instance, create a foreign server:
```
test=> CREATE SERVER mysqldb FOREIGN DATA WRAPPER mysql_fdw OPTIONS (host 'your-DB.aws-region.rds.amazonaws.com', port '3306');
CREATE SERVER
```
1. Grant usage to a user who doesn't have `rds_superuser` permissions, for example, `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER mysqldb TO user1;
GRANT
```
1. Connect as *user1*, and then create a mapping to the MySQL user:
```
test=> CREATE USER MAPPING FOR user1 SERVER mysqldb OPTIONS (username 'myuser', password 'mypassword');
CREATE USER MAPPING
```
1. Create a foreign table linked to the MySQL table:
```
test=> CREATE FOREIGN TABLE mytab (a int, b text) SERVER mysqldb OPTIONS (dbname 'test', table_name '');
CREATE FOREIGN TABLE
```
1. Run a simple query against the foreign table:
```
test=> SELECT * FROM mytab;
a | b
---+-------
1 | apple
(1 row)
```
1. You can add, change, and remove data from the MySQL table. For example:
```
test=> INSERT INTO mytab values (2, 'mango');
INSERT 0 1
```
Run the `SELECT` query again to see the results:
```
test=> SELECT * FROM mytab ORDER BY 1;
a | b
---+-------
1 | apple
2 | mango
(2 rows)
```
## Using encryption in transit with the extension
The connection to MySQL from Aurora PostgreSQL uses encryption in transit (TLS/SSL) by default. However, the connection falls back to non-encrypted when the client and server configuration differ. You can enforce encryption for all outgoing connections by specifying the `REQUIRE SSL` option on the RDS for MySQL user accounts. This same approach also works for MariaDB and Aurora MySQL user accounts.
For MySQL user accounts configured to `REQUIRE SSL`, the connection attempt fails if a secure connection can't be established.
To enforce encryption for existing MySQL database user accounts, you can use the `ALTER USER` command. The syntax varies, depending on the MySQL version, as shown in the following table. For more information, see [ALTER USER](https://dev.mysql.com/doc/refman/8.0/en/alter-user.html) in *MySQL Reference Manual*.
| MySQL 5.7, MySQL 8.0 | MySQL 5.6 |
| --- | --- |
| `ALTER USER 'user'@'%' REQUIRE SSL;` | `GRANT USAGE ON *.* to 'user'@'%' REQUIRE SSL;` |
For more information about the `mysql_fdw` extension, see the [mysql\$1fdw](https://github.com/EnterpriseDB/mysql_fdw) documentation.
# Working with Oracle databases by using the oracle\$1fdw extension
To access an Oracle database from your Aurora PostgreSQL DB cluster you can install and use the `oracle_fdw` extension. This extension is a foreign data wrapper for Oracle databases. To learn more about this extension, see the [oracle\$1fdw](https://github.com/laurenz/oracle_fdw) documentation.
The `oracle_fdw` extension is supported on Aurora PostgreSQL 12.7 (Amazon Aurora release 4.2) and higher versions.
**Topics**
+ [Turning on the oracle\$1fdw extension](#postgresql-oracle-fdw.enabling)
+ [Example: Using a foreign server linked to an Amazon RDS for Oracle database](#postgresql-oracle-fdw.example)
+ [Working with encryption in transit](#postgresql-oracle-fdw.encryption)
+ [Understanding the pg\$1user\$1mappings view and permissions](#postgresql-oracle-fdw.permissions)
## Turning on the oracle\$1fdw extension
To use the oracle\$1fdw extension, perform the following procedure.
**To turn on the oracle\$1fdw extension**
+ Run the following command using an account that has `rds_superuser` permissions.
```
CREATE EXTENSION oracle_fdw;
```
## Example: Using a foreign server linked to an Amazon RDS for Oracle database
The following example shows the use of a foreign server linked to an Amazon RDS for Oracle database.
**To create a foreign server linked to an RDS for Oracle database**
1. Note the following on the RDS for Oracle DB instance:
+ Endpoint
+ Port
+ Database name
1. Create a foreign server.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Grant usage to a user who doesn't have `rds_superuser` privileges, for example `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Connect as `user1`, and create a mapping to an Oracle user.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Create a foreign table linked to an Oracle table.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Query the foreign table.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
If the query reports the following error, check your security group and access control list (ACL) to make sure that both instances can communicate.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Working with encryption in transit
PostgreSQL-to-Oracle encryption in transit is based on a combination of client and server configuration parameters. For an example using Oracle 21c, see [About the Values for Negotiating Encryption and Integrity](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) in the Oracle documentation. The client used for oracle\$1fdw on Amazon RDS is configured with `ACCEPTED`, meaning that the encryption depends on the Oracle database server configuration and it uses Oracle Security Library (libnnz) for encryption.
If your database is on RDS for Oracle, see [Oracle native network encryption](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) to configure the encryption.
## Understanding the pg\$1user\$1mappings view and permissions
The PostgreSQL catalog `pg_user_mapping` stores the mapping from an Aurora PostgreSQL user to the user on a foreign data (remote) server. Access to the catalog is restricted, but you use the `pg_user_mappings` view to see the mappings. In the following, you can find an example that shows how permissions apply with an example Oracle database, but this information applies more generally to any foreign data wrapper.
In the following output, you can find roles and permissions mapped to three different example users. Users `rdssu1` and `rdssu2` are members of the `rds_superuser` role, and `user1` isn't. The example uses the `psql` metacommand `\du` to list existing roles.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
All users, including users that have `rds_superuser` privileges, are allowed to view their own user mappings (`umoptions`) in the `pg_user_mappings` table. As shown in the following example, when `rdssu1` tries to obtain all user mappings, an error is raised even though `rdssu1``rds_superuser` privileges:
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
Following are some examples.
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
Because of implementation differences between `information_schema._pg_user_mappings` and `pg_catalog.pg_user_mappings`, a manually created `rds_superuser` requires additional permissions to view passwords in `pg_catalog.pg_user_mappings`.
No additional permissions are required for an `rds_superuser` to view passwords in `information_schema._pg_user_mappings`.
Users who don't have the `rds_superuser` role can view passwords in `pg_user_mappings` only under the following conditions:
+ The current user is the user being mapped and owns the server or holds the `USAGE` privilege on it.
+ The current user is the server owner and the mapping is for `PUBLIC`.
# Working with SQL Server databases by using the tds\$1fdw extension
You can use the PostgreSQL `tds_fdw` extension to access databases that support the tabular data stream (TDS) protocol, such as Sybase and Microsoft SQL Server databases. This foreign data wrapper lets you connect from your Aurora PostgreSQL DB cluster to databases that use the TDS protocol, including Amazon RDS for Microsoft SQL Server. For more information, see [tds-fdw/tds\$1fdw](https://github.com/tds-fdw/tds_fdw) documentation on GitHub.
The `tds_fdw` extension is supported on Amazon Aurora PostgreSQL version 13.6 and higher releases.
## Setting up your Aurora PostgreSQL DB to use the tds\$1fdw extension
In the following procedures, you can find an example of setting up and using the `tds_fdw` with an Aurora PostgreSQL DB cluster. Before you can connect to a SQL Server database using `tds_fdw`, you need to get the following details for the instance:
+ Hostname or endpoint. For an RDS for SQL Server DB instance, you can find the endpoint by using the Console. Choose the Connectivity & security tab and look in the "Endpoint and port" section.
+ Port number. The default port number for Microsoft SQL Server is 1433.
+ Name of the database. The DB identifier.
You also need to provide access on the security group or the access control list (ACL) for the SQL Server port, 1433. Both the Aurora PostgreSQL DB cluster and the RDS for SQL Server DB instance need access to port 1433. If access isn't configured correctly, when you try to query the Microsoft SQL Server you see the following error message:
```
ERROR: DB-Library error: DB #: 20009, DB Msg: Unable to connect:
Adaptive Server is unavailable or does not exist (mssql2019.aws-region.rds.amazonaws.com), OS #: 0, OS Msg: Success, Level: 9
```
**To use tds\$1fdw to connect to a SQL Server database**
1. Connect to your Aurora PostgreSQL DB cluster's primary instance using an account that has the `rds_superuser` role:
```
psql --host=your-cluster-name-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=test –-password
```
1. Install the `tds_fdw` extension:
```
test=> CREATE EXTENSION tds_fdw;
CREATE EXTENSION
```
After the extension is installed on your Aurora PostgreSQL DB cluster , you set up the foreign server.
**To create the foreign server**
Perform these tasks on the Aurora PostgreSQL DB cluster using an account that has `rds_superuser` privileges.
1. Create a foreign server in the Aurora PostgreSQL DB cluster:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing');
CREATE SERVER
```
To access non-ASCII data on the SQLServer side, create a server link with the character\$1set option in the Aurora PostgreSQL DB cluster:
```
test=> CREATE SERVER sqlserverdb FOREIGN DATA WRAPPER tds_fdw OPTIONS (servername 'mssql2019.aws-region.rds.amazonaws.com', port '1433', database 'tds_fdw_testing', character_set 'UTF-8');
CREATE SERVER
```
1. Grant permissions to a user who doesn't have `rds_superuser` role privileges, for example, `user1`:
```
test=> GRANT USAGE ON FOREIGN SERVER sqlserverdb TO user1;
```
1. Connect as user1 and create a mapping to a SQL Server user:
```
test=> CREATE USER MAPPING FOR user1 SERVER sqlserverdb OPTIONS (username 'sqlserveruser', password 'password');
CREATE USER MAPPING
```
1. Create a foreign table linked to a SQL Server table:
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER sqlserverdb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Query the foreign table:
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
### Using encryption in transit for the connection
The connection from Aurora PostgreSQL to SQL Server uses encryption in transit (TLS/SSL) depending on the SQL Server database configuration. If the SQL Server isn't configured for encryption, the RDS for PostgreSQL client making the request to the SQL Server database falls back to unencrypted.
You can enforce encryption for the connection to RDS for SQL Server DB instances by setting the `rds.force_ssl` parameter. To learn how, see [Forcing connections to your DB instance to use SSL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html#SQLServer.Concepts.General.SSL.Forcing). For more information about SSL/TLS configuration for RDS for SQL Server, see [Using SSL with a Microsoft SQL Server DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html).
# Working with Trusted Language Extensions for PostgreSQL
Trusted Language Extensions for PostgreSQL is an open source development kit for building PostgreSQL extensions. It allows you to build high performance PostgreSQL extensions and safely run them on your Aurora PostgreSQL DB cluster. By using Trusted Language Extensions (TLE) for PostgreSQL, you can create PostgreSQL extensions that follow the documented approach for extending PostgreSQL functionality. For more information, see [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) in the PostgreSQL documentation.
One key benefit of TLE is that you can use it in environments that don't provide access to the file system underlying the PostgreSQL instance. Previously, installing a new extension required access to the file system. TLE removes this constraint. It provides a development environment for creating new extensions for any PostgreSQL database, including those running on your Aurora PostgreSQL DB clusters.
TLE is designed to prevent access to unsafe resources for the extensions that you create using TLE. Its runtime environment limits the impact of any extension defect to a single database connection. TLE also gives database administrators fine-grained control over who can install extensions, and it provides a permissions model for running them.
TLE is supported on Aurora PostgreSQL version 14.5 and higher versions.
The Trusted Language Extensions development environment and runtime are packaged as the `pg_tle` PostgreSQL extension, version 1.0.1. It supports creating extensions in JavaScript, Perl, Tcl, PL/pgSQL, and SQL. You install the `pg_tle` extension in your Aurora PostgreSQL DB cluster in the same way that you install other PostgreSQL extensions. After the `pg_tle` is set up, developers can use it to create new PostgreSQL extensions, known as *TLE extensions*.
In the following topics, you can find information about how to set up Trusted Language Extensions and how to get started creating your own TLE extensions.
**Topics**
+ [Terminology](PostgreSQL_trusted_language_extension-terminology.md)
+ [Requirements for using Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-requirements.md)
+ [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md)
+ [Overview of Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension.overview.md)
+ [Creating TLE extensions for Aurora PostgreSQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md)
+ [Dropping your TLE extensions from a database](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md)
+ [Uninstalling Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-uninstalling-pg_tle-devkit.md)
+ [Using PostgreSQL hooks with your TLE extensions](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md)
+ [Function reference for Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md)
+ [Hooks reference for Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md)
# Terminology
To help you better understand Trusted Language Extensions, view the following glossary for terms used in this topic.
**Trusted Language Extensions for PostgreSQL**
*Trusted Language Extensions for PostgreSQL* is the official name of the open source development kit that's packaged as the `pg_tle` extension. It's available for use on any PostgreSQL system. For more information, see [aws/pg\$1tle](https://github.com/aws/pg_tle) on GitHub.
**Trusted Language Extensions**
*Trusted Language Extensions* is the short name for Trusted Language Extensions for PostgreSQL. This shortened name and its abbreviation (TLE) are also used in this documentation.
**trusted language**
A *trusted language* is a programming or scripting language that has specific security attributes. For example, trusted languages typically restrict access to the file system, and they limit use of specified networking properties. The TLE development kit is designed to support trusted languages. PostgreSQL supports several different languages that are used to create trusted or untrusted extensions. For an example, see [Trusted and Untrusted PL/Perl](https://www.postgresql.org/docs/current/plperl-trusted.html) in the PostgreSQL documentation. When you create an extension using Trusted Language Extensions, the extension inherently uses trusted language mechanisms.
**TLE extension**
A *TLE extension* is a PostgreSQL extension that's been created by using the Trusted Language Extensions (TLE) development kit.
# Requirements for using Trusted Language Extensions for PostgreSQL
The following are requirements for setting up and using the TLE development kit.
+ ** Aurora PostgreSQL versions ** – Trusted Language Extensions is supported on Aurora PostgreSQL version 14.5 and higher versions only.
+ If you need to upgrade your Aurora PostgreSQL DB cluster, see [Upgrading Amazon Aurora PostgreSQL DB clusters](USER_UpgradeDBInstance.PostgreSQL.md).
+ If you don't yet have an Aurora DB cluster running PostgreSQL, you can create one. For more information, see [Creating and connecting to an Aurora PostgreSQL DB cluster](CHAP_GettingStartedAurora.CreatingConnecting.AuroraPostgreSQL.md).
+ **Requires `rds_superuser` privileges** – To set up and configure the `pg_tle` extension, your database user role must have the permissions of the `rds_superuser` role. By default, this role is granted to the `postgres` user that creates the Aurora PostgreSQL DB cluster.
+ **Requires a custom DB parameter group** – Your Aurora PostgreSQL DB cluster must be configured with a custom DB parameter group. You use the custom DB parameter group for the writer instance of your Aurora PostgreSQL DB cluster.
+ If your Aurora PostgreSQL DB cluster isn't configured with a custom DB parameter group, you should create one and associate it with the writer instance of your Aurora PostgreSQL DB cluster. For a short summary of steps, see [Creating and applying a custom DB parameter group](#PostgreSQL_trusted_language_extension-requirements-create-custom-params).
+ If your Aurora PostgreSQL DB cluster is already configured using a custom DB parameter group, you can set up Trusted Language Extensions. For details, see [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md).
## Creating and applying a custom DB parameter group
Use the following steps to create a custom DB parameter group and configure your Aurora PostgreSQL DB cluster to use it.
### Console
**To create a custom DB parameter group and use it with your Aurora PostgreSQL DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Choose Parameter groups from the Amazon RDS menu.
1. Choose **Create parameter group**.
1. In the **Parameter group details** page, enter the following information.
+ For **Parameter group family**, choose aurora-postgresql14.
+ For **Type**, choose DB Parameter Group.
+ For **Group name**, give your parameter group a meaningful name in the context of your operations.
+ For **Description**, enter a useful description so that others on your team can easily find it.
1. Choose **Create**. Your custom DB parameter group is created in your AWS Region. You can now modify your Aurora PostgreSQL DB cluster to use it by following the next steps.
1. Choose **Databases** from the Amazon RDS menu.
1. Choose the Aurora PostgreSQL DB cluster that you want to use with TLE from among those listed, and then choose **Modify.**
1. In the Modify DB cluster settings page, find **Database options** and use the selector to choose your custom DB parameter group.
1. Choose **Continue** to save the change.
1. Choose **Apply immediately** so that you can continue setting up the Aurora PostgreSQL DB cluster to use TLE.
To continue setting up your system for Trusted Language Extensions, see [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md).
For more information working with DB cluster and DB parameter groups, see [DB cluster parameter groups for Amazon Aurora DB clusters](USER_WorkingWithDBClusterParamGroups.md).
### AWS CLI
You can avoid specifying the `--region` argument when you use CLI commands by configuring your AWS CLI with your default AWS Region. For more information, see [Configuration basics](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) in the *AWS Command Line Interface User Guide*.
**To create a custom DB parameter group and use it with your Aurora PostgreSQL DB cluster**
1. Use the [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI command to create a custom DB parameter group based on aurora-postgresql14 for your AWS Region. Note that in this step you create a DB parameter group to apply to the writer instance of your Aurora PostgreSQL DB cluster.
For Linux, macOS, or Unix:
```
aws rds create-db-parameter-group \
--region aws-region \
--db-parameter-group-name custom-params-for-pg-tle \
--db-parameter-group-family aurora-postgresql14 \
--description "My custom DB parameter group for Trusted Language Extensions"
```
For Windows:
```
aws rds create-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name custom-params-for-pg-tle ^
--db-parameter-group-family aurora-postgresql14 ^
--description "My custom DB parameter group for Trusted Language Extensions"
```
Your custom DB parameter group is available in your AWS Region, so you can modify the writer instance of your Aurora PostgreSQL DB cluster to use it.
1. Use the [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) AWS CLI command to apply your custom DB parameter group to the writer instance of your Aurora PostgreSQL DB cluster. This command immediately reboots the active instance.
For Linux, macOS, or Unix:
```
aws rds modify-db-instance \
--region aws-region \
--db-instance-identifier your-writer-instance-name \
--db-parameter-group-name custom-params-for-pg-tle \
--apply-immediately
```
For Windows:
```
aws rds modify-db-instance ^
--region aws-region ^
--db-instance-identifier your-writer-instance-name ^
--db-parameter-group-name custom-params-for-pg-tle ^
--apply-immediately
```
To continue setting up your system for Trusted Language Extensions, see [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md).
For more information, see [DB parameter groups for Amazon Aurora DB instances](USER_WorkingWithDBInstanceParamGroups.md) .
# Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster
The following steps assume that your Aurora PostgreSQL DB cluster is associated with a custom DB cluster parameter group. You can use the AWS Management Console or the AWS CLI for these steps.
When you set up Trusted Language Extensions in your Aurora PostgreSQL DB cluster , you install it in a specific database for use by the database users who have permissions on that database.
## Console
**To set up Trusted Language Extensions**
Perform the following steps using an account that's a member of the `rds_superuser` group (role).
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose your Aurora PostgreSQL DB cluster's Writer instance .
1. Open the **Configuration** tab for your Aurora PostgreSQL DB cluster writer instance. Among the Instance details, find the **Parameter group** link.
1. Choose the link to open the custom parameters associated with your Aurora PostgreSQL DB cluster.
1. In the **Parameters** search field, type `shared_pre` to find the `shared_preload_libraries` parameter.
1. Choose **Edit parameters** to access the property values.
1. Add `pg_tle` to the list in the **Values** field. Use a comma to separate items in the list of values.
![\[Image of the shared_preload_libraries parameter with pg_tle added.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg_rpg_shared_preload_pg_tle.png)
1. Reboot the writer instance of your Aurora PostgreSQL DB cluster so that your change to the `shared_preload_libraries` parameter takes effect.
1. When the instance is available, verify that `pg_tle` has been initialized. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster, and then run the following command.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
1. With the `pg_tle` extension initialized, you can now create the extension.
```
CREATE EXTENSION pg_tle;
```
You can verify that the extension is installed by using the following `psql` metacommand.
```
labdb=> \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+--------------------------------------------
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
```
1. Grant the `pgtle_admin` role to the primary user name that you created for your Aurora PostgreSQL DB cluster when you set it up. If you accepted the default, it's `postgres`.
```
labdb=> GRANT pgtle_admin TO postgres;
GRANT ROLE
```
You can verify that the grant has occurred by using the `psql` metacommand as shown in the following example. Only the `pgtle_admin` and `postgres` roles are shown in the output. For more information, see [Understanding PostgreSQL roles and permissions](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
```
labdb=> \du
List of roles
Role name | Attributes | Member of
-----------------+---------------------------------+-----------------------------------
pgtle_admin | Cannot login | {}
postgres | Create role, Create DB +| {rds_superuser,pgtle_admin}
| Password valid until infinity |...
```
1. Close the `psql` session using the `\q` metacommand.
```
\q
```
To get started creating TLE extensions, see [Example: Creating a trusted language extension using SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
## AWS CLI
You can avoid specifying the `--region` argument when you use CLI commands by configuring your AWS CLI with your default AWS Region. For more information, see [Configuration basics](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) in the *AWS Command Line Interface User Guide*.
**To set up Trusted Language Extensions**
1. Use the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI command to add `pg_tle` to the `shared_preload_libraries` parameter.
```
aws rds modify-db-parameter-group \
--db-parameter-group-name custom-param-group-name \
--parameters "ParameterName=shared_preload_libraries,ParameterValue=pg_tle,ApplyMethod=pending-reboot" \
--region aws-region
```
1. Use the [reboot-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance) AWS CLI command to reboot the writer instance of your Aurora PostgreSQL DB cluster and initialize the `pg_tle` library.
```
aws rds reboot-db-instance \
--db-instance-identifier writer-instance \
--region aws-region
```
1. When the instance is available, you can verify that `pg_tle` has been initialized. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster, and then run the following command.
```
SHOW shared_preload_libraries;
shared_preload_libraries
--------------------------
rdsutils,pg_tle
(1 row)
```
With `pg_tle` initialized, you can now create the extension.
```
CREATE EXTENSION pg_tle;
```
1. Grant the `pgtle_admin` role to the primary user name that you created for your Aurora PostgreSQL DB cluster when you set it up. If you accepted the default, it's `postgres`.
```
GRANT pgtle_admin TO postgres;
GRANT ROLE
```
1. Close the `psql` session as follows.
```
labdb=> \q
```
To get started creating TLE extensions, see [Example: Creating a trusted language extension using SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example).
# Overview of Trusted Language Extensions for PostgreSQL
Trusted Language Extensions for PostgreSQL is a PostgreSQL extension that you install in your Aurora PostgreSQL DB cluster in the same way that you set up other PostgreSQL extensions. In the following image of an example database in the pgAdmin client tool, you can view some of the components that comprise the `pg_tle` extension.
![\[Image showing some of the components that make up the TLE development kit.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-pg_tle-installed-view-in-pgAdmin.png)
You can see the following details.
1. The Trusted Language Extensions (TLE) for PostgreSQL development kit is packaged as the `pg_tle` extension. As such, `pg_tle` is added to the available extensions for the database in which it's installed.
1. TLE has its own schema, `pgtle`. This schema contains helper functions (3) for installing and managing the extensions that you create.
1. TLE provides over a dozen helper functions for installing, registering, and managing your extensions. To learn more about these functions, see [Function reference for Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-functions-reference.md).
Other components of the `pg_tle` extension include the following:
+ **The `pgtle_admin` role** – The `pgtle_admin` role is created when the `pg_tle` extension is installed. This role is privileged and should be treated as such. We strongly recommend that you follow the principle of *least privilege* when granting the `pgtle_admin` role to database users. In other words, grant the `pgtle_admin` role only to database users that are allowed to create, install, and manage new TLE extensions, such as `postgres`.
+ **The `pgtle.feature_info` table** – The `pgtle.feature_info` table is a protected table that contains information about your TLEs, hooks, and the custom stored procedures and functions that they use. If you have `pgtle_admin` privileges, you use the following Trusted Language Extensions functions to add and update that information in the table.
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
# Creating TLE extensions for Aurora PostgreSQL
You can install any extensions that you create with TLE in any Aurora PostgreSQL DB cluster that has the `pg_tle` extension installed. The `pg_tle` extension is scoped to the PostgreSQL database in which it's installed. The extensions that you create using TLE are scoped to the same database.
Use the various `pgtle` functions to install the code that makes up your TLE extension. The following Trusted Language Extensions functions all require the `pgtle_admin` role.
+ [pgtle.install\$1extension](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path)
+ [pgtle.register\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(name, version)](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.unregister_feature_if_exists)
## Example: Creating a trusted language extension using SQL
The following example shows you how to create a TLE extension named `pg_distance` that contains a few SQL functions for calculating distances using different formulas. In the listing, you can find the function for calculating the Manhattan distance and the function for calculating the Euclidean distance. For more information about the difference between these formulas, see [Taxicab geometry](https://en.wikipedia.org/wiki/Taxicab_geometry) and [Euclidean geometry](https://en.wikipedia.org/wiki/Euclidean_geometry) in Wikipedia.
You can use this example in your own Aurora PostgreSQL DB cluster if you have the `pg_tle` extension set up as detailed in [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md).
**Note**
You need to have the privileges of the `pgtle_admin` role to follow this procedure.
**To create the example TLE extension**
The following steps use an example database named `labdb`. This database is owned by the `postgres` primary user. The `postgres` role also has the permissions of the `pgtle_admin` role.
1. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Create a TLE extension named `pg_distance` by copying the following code and pasting it into your `psql` session console.
```
SELECT pgtle.install_extension
(
'pg_distance',
'0.1',
'Distance functions for two points',
$_pg_tle_$
CREATE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL;
CREATE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL;
CREATE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL;
$_pg_tle_$
);
```
You see the output, such as the following.
```
install_extension
---------------
t
(1 row)
```
The artifacts that make up the `pg_distance` extension are now installed in your database. These artifacts include the control file and the code for the extension, which are items that need to be present so that the extension can be created using the `CREATE EXTENSION` command. In other words, you still need to create the extension to make its functions available to database users.
1. To create the extension, use the `CREATE EXTENSION` command as you do for any other extension. As with other extensions, the database user needs to have the `CREATE` permissions in the database.
```
CREATE EXTENSION pg_distance;
```
1. To test the `pg_distance` TLE extension, you can use it to calculate the [Manhattan distance](https://en.wikipedia.org/wiki/Taxicab_geometry) between four points.
```
labdb=> SELECT manhattan_dist(1, 1, 5, 5);
8
```
To calculate the [Euclidean distance](https://en.wikipedia.org/wiki/Euclidean_geometry) between the same set of points, you can use the following.
```
labdb=> SELECT euclidean_dist(1, 1, 5, 5);
5.656854249492381
```
The `pg_distance` extension loads the functions in the database and makes them available to any users with permissions on the database.
## Modifying your TLE extension
To improve query performance for the functions packaged in this TLE extension, add the following two PostgreSQL attributes to their specifications.
+ `IMMUTABLE` – The `IMMUTABLE` attribute ensures that the query optimizer can use optimizations to improve query response times. For more information, see [Function Volatility Categories](https://www.postgresql.org/docs/current/xfunc-volatility.html) in the PostgreSQL documentation.
+ `PARALLEL SAFE` – The `PARALLEL SAFE` attribute is another attribute that allows PostgreSQL to run the function in parallel mode. For more information, see [CREATE FUNCTION](https://www.postgresql.org/docs/current/sql-createfunction.html) in the PostgreSQL documentation.
In the following example, you can see how the `pgtle.install_update_path` function is used to add these attributes to each function to create a version `0.2` of the `pg_distance` TLE extension. For more information about this function, see [pgtle.install\$1update\$1path](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.install_update_path). You need to have the `pgtle_admin` role to perform this task.
**To update an existing TLE extension and specify the default version**
1. Connect to the writer instance of your Aurora PostgreSQL DB cluster using `psql` or another client tool, such as pgAdmin.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Modify the existing TLE extension by copying the following code and pasting it into your `psql` session console.
```
SELECT pgtle.install_update_path
(
'pg_distance',
'0.1',
'0.2',
$_pg_tle_$
CREATE OR REPLACE FUNCTION dist(x1 float8, y1 float8, x2 float8, y2 float8, norm int)
RETURNS float8
AS $$
SELECT (abs(x2 - x1) ^ norm + abs(y2 - y1) ^ norm) ^ (1::float8 / norm);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION manhattan_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 1);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
CREATE OR REPLACE FUNCTION euclidean_dist(x1 float8, y1 float8, x2 float8, y2 float8)
RETURNS float8
AS $$
SELECT dist(x1, y1, x2, y2, 2);
$$ LANGUAGE SQL IMMUTABLE PARALLEL SAFE;
$_pg_tle_$
);
```
You see a response similar to the following.
```
install_update_path
---------------------
t
(1 row)
```
You can make this version of the extension the default version, so that database users don't have to specify a version when they create or update the extension in their database.
1. To specify that the modified version (version 0.2) of your TLE extension is the default version, use the `pgtle.set_default_version` function as shown in the following example.
```
SELECT pgtle.set_default_version('pg_distance', '0.2');
```
For more information about this function, see [pgtle.set\$1default\$1version](PostgreSQL_trusted_language_extension-functions-reference.md#pgtle.set_default_version).
1. With the code in place, you can update the installed TLE extension in the usual way, by using `ALTER EXTENSION ... UPDATE` command, as shown here:
```
ALTER EXTENSION pg_distance UPDATE;
```
# Dropping your TLE extensions from a database
You can drop your TLE extensions by using the `DROP EXTENSION` command in the same way that you do for other PostgreSQL extensions. Dropping the extension doesn't remove the installation files that make up the extension, which allows users to re-create the extension. To remove the extension and its installation files, do the following two-step process.
**To drop the TLE extension and remove its installation files**
1. Use `psql` or another client tool to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Drop the extension as you would any PostgreSQL extension.
```
DROP EXTENSION your-TLE-extension
```
For example, if you create the `pg_distance` extension as detailed in [Example: Creating a trusted language extension using SQL](PostgreSQL_trusted_language_extension-creating-TLE-extensions.md#PostgreSQL_trusted_language_extension-simple-example), you can drop the extension as follows.
```
DROP EXTENSION pg_distance;
```
You see output confirming that the extension has been dropped, as follows.
```
DROP EXTENSION
```
At this point, the extension is no longer active in the database. However, its installation files and control file are still available in the database, so database users can create the extension again if they like.
+ If you want to leave the extension files intact so that database users can create your TLE extension, you can stop here.
+ If you want to remove all files that make up the extension, continue to the next step.
1. To remove all installation files for your extension, use the `pgtle.uninstall_extension` function. This function removes all the code and control files for your extension.
```
SELECT pgtle.uninstall_extension('your-tle-extension-name');
```
For example, to remove all `pg_distance` installation files, use the following command.
```
SELECT pgtle.uninstall_extension('pg_distance');
uninstall_extension
---------------------
t
(1 row)
```
# Uninstalling Trusted Language Extensions for PostgreSQL
If you no longer want to create your own TLE extensions using TLE, you can drop the `pg_tle` extension and remove all artifacts. This action includes dropping any TLE extensions in the database and dropping the `pgtle` schema.
**To drop the `pg_tle` extension and its schema from a database**
1. Use `psql` or another client tool to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=cluster-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=dbname
```
1. Drop the `pg_tle` extension from the database. If the database has your own TLE extensions still running in the database, you need to also drop those extensions. To do so, you can use the `CASCADE` keyword, as shown in the following.
```
DROP EXTENSION pg_tle CASCADE;
```
If the `pg_tle` extension isn't still active in the database, you don't need to use the `CASCADE` keyword.
1. Drop the `pgtle` schema. This action removes all the management functions from the database.
```
DROP SCHEMA pgtle CASCADE;
```
The command returns the following when the process completes.
```
DROP SCHEMA
```
The `pg_tle` extension, its schema and functions, and all artifacts are removed. To create new extensions using TLE, go through the setup process again. For more information, see [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md).
# Using PostgreSQL hooks with your TLE extensions
A *hook* is a callback mechanism available in PostgreSQL that allows developers to call custom functions or other routines during regular database operations. The TLE development kit supports PostgreSQL hooks so that you can integrate custom functions with PostgreSQL behavior at runtime. For example, you can use a hook to associate the authentication process with your own custom code, or to modify the query planning and execution process for your specific needs.
Your TLE extensions can use hooks. If a hook is global in scope, it applies across all databases. Therefore, if your TLE extension uses a global hook, then you need to create your TLE extension in all databases that your users can access.
When you use the `pg_tle` extension to build your own Trusted Language Extensions, you can use the available hooks from a SQL API to build out the functions of your extension. You should register any hooks with `pg_tle`. For some hooks, you might also need to set various configuration parameters. For example, the `passcode` check hook can be set to on, off, or require. For more information about specific requirements for available `pg_tle` hooks, see [Hooks reference for Trusted Language Extensions for PostgreSQL](PostgreSQL_trusted_language_extension-hooks-reference.md).
## Example: Creating an extension that uses a PostgreSQL hook
The example discussed in this section uses a PostgreSQL hook to check the password provided during specific SQL operations and prevents database users from setting their passwords to any of those contained in the `password_check.bad_passwords` table. The table contains the top-ten most commonly used, but easily breakable choices for passwords.
To set up this example in your Aurora PostgreSQL DB cluster, you must have already installed Trusted Language Extensions. For details, see [Setting up Trusted Language Extensions in your Aurora PostgreSQL DB cluster](PostgreSQL_trusted_language_extension-setting-up.md).
**To set up the password-check hook example**
1. Use `psql` to connect to the writer instance of your Aurora PostgreSQL DB cluster.
```
psql --host=db-instance-123456789012.aws-region.rds.amazonaws.com
--port=5432 --username=postgres --password --dbname=labdb
```
1. Copy the code from the [Password-check hook code listing](#PostgreSQL_trusted_language_extension-example-hook_code_listing) and paste it into your database.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
When the extension has been loaded into your database, you see the output such as the following.
```
install_extension
-------------------
t
(1 row)
```
1. While still connected to the database, you can now create the extension.
```
CREATE EXTENSION my_password_check_rules;
```
1. You can confirm that the extension has been created in the database by using the following `psql` metacommand.
```
\dx
List of installed extensions
Name | Version | Schema | Description
-------------------------+---------+------------+-------------------------------------------------------------
my_password_check_rules | 1.0 | public | Prevent use of any of the top-ten most common bad passwords
pg_tle | 1.0.1 | pgtle | Trusted-Language Extensions for PostgreSQL
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
(3 rows)
```
1. Open another terminal session to work with the AWS CLI. You need to modify your custom DB parameter group to turn on the password-check hook. To do so, use the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) CLI command as shown in the following example.
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
It might take a few minutes for the change to the parameter group setting to take effect. This parameter is dynamic, however, so you don't need to restart the writer instance of the Aurora PostgreSQL DB cluster for the setting to take effect.
1. Open the `psql` session and query the database to verify that the password\$1check hook has been turned on.
```
labdb=> SHOW pgtle.enable_password_check;
pgtle.enable_password_check
-----------------------------
on
(1 row)
```
The password-check hook is now active. You can test it by creating a new role and using one of the bad passwords, as shown in the following example.
```
CREATE ROLE test_role PASSWORD 'password';
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 21 at RAISE
SQL statement "SELECT password_check.passcheck_hook(
$1::pg_catalog.text,
$2::pg_catalog.text,
$3::pgtle.password_types,
$4::pg_catalog.timestamptz,
$5::pg_catalog.bool)"
```
The output has been formatted for readability.
The following example shows that `pgsql` interactive metacommand `\password` behavior is also affected by the password\$1check hook.
```
postgres=> SET password_encryption TO 'md5';
SET
postgres=> \password
Enter new password for user "postgres":*****
Enter it again:*****
ERROR: Cannot use passwords from the common password dictionary
CONTEXT: PL/pgSQL function password_check.passcheck_hook(text,text,pgtle.password_types,timestamp with time zone,boolean) line 12 at RAISE
SQL statement "SELECT password_check.passcheck_hook($1::pg_catalog.text, $2::pg_catalog.text, $3::pgtle.password_types, $4::pg_catalog.timestamptz, $5::pg_catalog.bool)"
```
You can drop this TLE extension and uninstall its source files if you want. For more information, see [Dropping your TLE extensions from a databaseDropping your TLE extensions from a database](PostgreSQL_trusted_language_extension-creating-TLE-extensions.dropping-TLEs.md).
### Password-check hook code listing
The example code shown here defines the specification for the `my_password_check_rules` TLE extension. When you copy this code and paste it into your database, the code for the `my_password_check_rules` extension is loaded into the database, and the `password_check` hook is registered for use by the extension.
```
SELECT pgtle.install_extension (
'my_password_check_rules',
'1.0',
'Do not let users use the 10 most commonly used passwords',
$_pgtle_$
CREATE SCHEMA password_check;
REVOKE ALL ON SCHEMA password_check FROM PUBLIC;
GRANT USAGE ON SCHEMA password_check TO PUBLIC;
CREATE TABLE password_check.bad_passwords (plaintext) AS
VALUES
('123456'),
('password'),
('12345678'),
('qwerty'),
('123456789'),
('12345'),
('1234'),
('111111'),
('1234567'),
('dragon');
CREATE UNIQUE INDEX ON password_check.bad_passwords (plaintext);
CREATE FUNCTION password_check.passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
RETURNS void AS $$
DECLARE
invalid bool := false;
BEGIN
IF password_type = 'PASSWORD_TYPE_MD5' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE ('md5' || md5(bp.plaintext || username)) = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
ELSIF password_type = 'PASSWORD_TYPE_PLAINTEXT' THEN
SELECT EXISTS(
SELECT 1
FROM password_check.bad_passwords bp
WHERE bp.plaintext = password
) INTO invalid;
IF invalid THEN
RAISE EXCEPTION 'Cannot use passwords from the common password dictionary';
END IF;
END IF;
END
$$ LANGUAGE plpgsql SECURITY DEFINER;
GRANT EXECUTE ON FUNCTION password_check.passcheck_hook TO PUBLIC;
SELECT pgtle.register_feature('password_check.passcheck_hook', 'passcheck');
$_pgtle_$
);
```
# Function reference for Trusted Language Extensions for PostgreSQL
View the following reference documentation about functions available in Trusted Language Extensions for PostgreSQL. Use these functions to install, register, update, and manage your *TLE extensions*, that is, the PostgreSQL extensions that you develop using the Trusted Language Extensions development kit.
**Topics**
+ [pgtle.available\$1extensions](#pgtle.available_extensions)
+ [pgtle.available\$1extension\$1versions](#pgtle.available_extension_versions)
+ [pgtle.extension\$1update\$1paths](#pgtle.extension_update_paths)
+ [pgtle.install\$1extension](#pgtle.install_extension)
+ [pgtle.install\$1update\$1path](#pgtle.install_update_path)
+ [pgtle.register\$1feature](#pgtle.register_feature)
+ [pgtle.register\$1feature\$1if\$1not\$1exists](#pgtle.register_feature_if_not_exists)
+ [pgtle.set\$1default\$1version](#pgtle.set_default_version)
+ [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name)
+ [pgtle.uninstall\$1extension(name, version)](#pgtle.uninstall_extension-name-version)
+ [pgtle.uninstall\$1extension\$1if\$1exists](#pgtle.uninstall_extension_if_exists)
+ [pgtle.uninstall\$1update\$1path](#pgtle.uninstall_update_path)
+ [pgtle.uninstall\$1update\$1path\$1if\$1exists](#pgtle.uninstall_update_path_if_exists)
+ [pgtle.unregister\$1feature](#pgtle.unregister_feature)
+ [pgtle.unregister\$1feature\$1if\$1exists](#pgtle.unregister_feature_if_exists)
## pgtle.available\$1extensions
The `pgtle.available_extensions` function is a set-returning function. It returns all available TLE extensions in the database. Each returned row contains information about a single TLE extension.
### Function prototype
```
pgtle.available_extensions()
```
### Role
None.
### Arguments
None.
### Output
+ `name` – The name of the TLE extension.
+ `default_version` – The version of the TLE extension to use when `CREATE EXTENSION` is called without a version specified.
+ `description` – A more detailed description about the TLE extension.
### Usage example
```
SELECT * FROM pgtle.available_extensions();
```
## pgtle.available\$1extension\$1versions
The `available_extension_versions` function is a set-returning function. It returns a list of all available TLE extensions and their versions. Each row contains information about a specific version of the given TLE extension, including whether it requires a specific role.
### Function prototype
```
pgtle.available_extension_versions()
```
### Role
None.
### Arguments
None.
### Output
+ `name` – The name of the TLE extension.
+ `version` – The version of the TLE extension.
+ `superuser` – This value is always `false` for your TLE extensions. The permissions needed to create the TLE extension or update it are the same as for creating other objects in the given database.
+ `trusted` – This value is always `false` for a TLE extension.
+ `relocatable` – This value is always `false` for a TLE extension.
+ `schema` – Specifies the name of the schema in which the TLE extension is installed.
+ `requires` – An array containing the names of other extensions needed by this TLE extension.
+ `description` – A detailed description of the TLE extension.
For more information about output values, see [Packaging Related Objects into an Extension > Extension Files](https://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) in the PostgreSQL documentation.
### Usage example
```
SELECT * FROM pgtle.available_extension_versions();
```
## pgtle.extension\$1update\$1paths
The `extension_update_paths` function is a set-returning function. It returns a list of all the possible update paths for a TLE extension. Each row includes the available upgrades or downgrades for that TLE extension.
### Function prototype
```
pgtle.extension_update_paths(name)
```
### Role
None.
### Arguments
`name` – The name of the TLE extension from which to get upgrade paths.
### Output
+ `source` – The source version for an update.
+ `target` – The target version for an update.
+ `path` – The upgrade path used to update a TLE extension from `source` version to `target` version, for example, `0.1--0.2`.
### Usage example
```
SELECT * FROM pgtle.extension_update_paths('your-TLE');
```
## pgtle.install\$1extension
The `install_extension` function lets you install the artifacts that make up your TLE extension in the database, after which it can be created using the `CREATE EXTENSION` command.
### Function prototype
```
pgtle.install_extension(name text, version text, description text, ext text, requires text[] DEFAULT NULL::text[])
```
### Role
None.
### Arguments
+ `name` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
+ `version` – The version of the TLE extension.
+ `description` – A detailed description about the TLE extension. This description is displayed in the `comment` field in `pgtle.available_extensions()`.
+ `ext` – The contents of the TLE extension. This value contains objects such as functions.
+ `requires` – An optional parameter that specifies dependencies for this TLE extension. The `pg_tle` extension is automatically added as a dependency.
Many of these arguments are the same as those that are included in an extension control file for installing a PostgreSQL extension on the file system of a PostgreSQL instance. For more information, see the [Extension Files](http://www.postgresql.org/docs/current/extend-extensions.html#id-1.8.3.20.11) in [Packaging Related Objects into an Extension](https://www.postgresql.org/docs/current/extend-extensions.html) in the PostgreSQL documentation.
### Output
This functions returns `OK` on success and `NULL` on error.
+ `OK` – The TLE extension has been successfully installed in the database.
+ `NULL` – The TLE extension hasn't been successfully installed in the database.
### Usage example
```
SELECT pgtle.install_extension(
'pg_tle_test',
'0.1',
'My first pg_tle extension',
$_pgtle_$
CREATE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 42;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.install\$1update\$1path
The `install_update_path` function provides an update path between two different versions of a TLE extension. This function allows users of your TLE extension to update its version by using the `ALTER EXTENSION ... UPDATE` syntax.
### Function prototype
```
pgtle.install_update_path(name text, fromvers text, tovers text, ext text)
```
### Role
`pgtle_admin`
### Arguments
+ `name` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
+ `fromvers` – The source version of the TLE extension for the upgrade.
+ `tovers` – The destination version of the TLE extension for the upgrade.
+ `ext` – The contents of the update. This value contains objects such as functions.
### Output
None.
### Usage example
```
SELECT pgtle.install_update_path('pg_tle_test', '0.1', '0.2',
$_pgtle_$
CREATE OR REPLACE FUNCTION my_test()
RETURNS INT
AS $$
SELECT 21;
$$ LANGUAGE SQL IMMUTABLE;
$_pgtle_$
);
```
## pgtle.register\$1feature
The `register_feature` function adds the specified internal PostgreSQL feature to the `pgtle.feature_info` table. PostgreSQL hooks are an example of an internal PostgreSQL feature. The Trusted Language Extensions development kit supports the use of PostgreSQL hooks. Currently, this function supports the following feature.
+ `passcheck` – Registers the password-check hook with your procedure or function that customizes PostgreSQL's password-check behavior.
### Function prototype
```
pgtle.register_feature(proc regproc, feature pg_tle_feature)
```
### Role
`pgtle_admin`
### Arguments
+ `proc` – The name of a stored procedure or function to use for the feature.
+ `feature` – The name of the `pg_tle` feature (such as `passcheck`) to register with the function.
### Output
None.
### Usage example
```
SELECT pgtle.register_feature('pw_hook', 'passcheck');
```
## pgtle.register\$1feature\$1if\$1not\$1exists
The `pgtle.register_feature_if_not_exists` function adds the specified PostgreSQL feature to the `pgtle.feature_info` table and identifies the TLE extension or other procedure or function that uses the feature. For more information about hooks and Trusted Language Extensions, see [Using PostgreSQL hooks with your TLE extensions](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md).
### Function prototype
```
pgtle.register_feature_if_not_exists(proc regproc, feature pg_tle_feature)
```
### Role
`pgtle_admin`
### Arguments
+ `proc` – The name of a stored procedure or function that contains the logic (code) to use as a feature for your TLE extension. For example, the `pw_hook` code.
+ `feature` – The name of the PostgreSQL feature to register for the TLE function. Currently, the only available feature is the `passcheck` hook. For more information, see [Password-check hook (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Output
Returns `true` after registering the feature for the specified extension. Returns `false` if the feature is already registered.
### Usage example
```
SELECT pgtle.register_feature_if_not_exists('pw_hook', 'passcheck');
```
## pgtle.set\$1default\$1version
The `set_default_version` function lets you specify a `default_version` for your TLE extension. You can use this function to define an upgrade path and designate the version as the default for your TLE extension. When database users specify your TLE extension in the `CREATE EXTENSION` and `ALTER EXTENSION ... UPDATE` commands, that version of your TLE extension is created in the database for that user.
This function returns `true` on success. If the TLE extension specified in the `name` argument doesn't exist, the function returns an error. Similarly, if the `version` of the TLE extension doesn't exist, it returns an error.
### Function prototype
```
pgtle.set_default_version(name text, version text)
```
### Role
`pgtle_admin`
### Arguments
+ `name` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
+ `version` – The version of the TLE extension to set the default.
### Output
+ `true` – When setting default version succeeds, the function returns `true`.
+ `ERROR` – Returns an error message if a TLE extension with the specified name or version doesn't exist.
### Usage example
```
SELECT * FROM pgtle.set_default_version('my-extension', '1.1');
```
## pgtle.uninstall\$1extension(name)
The `uninstall_extension` function removes all versions of a TLE extension from a database. This function prevents future calls of `CREATE EXTENSION` from installing the TLE extension. If the TLE extension doesn't exist in the database, an error is raised.
The `uninstall_extension` function won't drop a TLE extension that's currently active in the database. To remove a TLE extension that's currently active, you need to explicitly call `DROP EXTENSION` to remove it.
### Function prototype
```
pgtle.uninstall_extension(extname text)
```
### Role
`pgtle_admin`
### Arguments
+ `extname` – The name of the TLE extension to uninstall. This name is the same as the one used with `CREATE EXTENSION` to load the TLE extension for use in a given database.
### Output
None.
### Usage example
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test');
```
## pgtle.uninstall\$1extension(name, version)
The `uninstall_extension(name, version)` function removes the specified version of the TLE extension from the database. This function prevents `CREATE EXTENSION` and `ALTER EXTENSION` from installing or updating a TLE extension to the specified version. This function also removes all update paths for the specified version of the TLE extension. This function won't uninstall the TLE extension if it's currently active in the database. You must explicitly call `DROP EXTENSION` to remove the TLE extension. To uninstall all versions of a TLE extension, see [pgtle.uninstall\$1extension(name)](#pgtle.uninstall_extension-name).
### Function prototype
```
pgtle.uninstall_extension(extname text, version text)
```
### Role
`pgtle_admin`
### Arguments
+ `extname` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
+ `version` – The version of the TLE extension to uninstall from the database.
### Output
None.
### Usage example
```
SELECT * FROM pgtle.uninstall_extension('pg_tle_test', '0.2');
```
## pgtle.uninstall\$1extension\$1if\$1exists
The `uninstall_extension_if_exists` function removes all versions of a TLE extension from a given database. If the TLE extension doesn't exist, the function returns silently (no error message is raised). If the specified extension is currently active within a database, this function doesn't drop it. You must explicitly call `DROP EXTENSION` to remove the TLE extension before using this function to uninstall its artifacts.
### Function prototype
```
pgtle.uninstall_extension_if_exists(extname text)
```
### Role
`pgtle_admin`
### Arguments
+ `extname` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
### Output
The `uninstall_extension_if_exists` function returns `true` after uninstalling the specified extension. If the specified extension doesn't exist, the function returns `false`.
+ `true` – Returns `true` after uninstalling the TLE extension.
+ `false` – Returns `false` when the TLE extension doesn't exist in the database.
### Usage example
```
SELECT * FROM pgtle.uninstall_extension_if_exists('pg_tle_test');
```
## pgtle.uninstall\$1update\$1path
The `uninstall_update_path` function removes the specific update path from a TLE extension. This prevents `ALTER EXTENSION ... UPDATE TO` from using this as an update path.
If the TLE extension is currently being used by one of the versions on this update path, it remains in the database.
If the update path specified doesn't exist, this function raises an error.
### Function prototype
```
pgtle.uninstall_update_path(extname text, fromvers text, tovers text)
```
### Role
`pgtle_admin`
### Arguments
+ `extname` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
+ `fromvers` – The source version of the TLE extension used on the update path.
+ `tovers` – The destination version of the TLE extension used on the update path.
### Output
None.
### Usage example
```
SELECT * FROM pgtle.uninstall_update_path('pg_tle_test', '0.1', '0.2');
```
## pgtle.uninstall\$1update\$1path\$1if\$1exists
The `uninstall_update_path_if_exists` function is similar to `uninstall_update_path` in that it removes the specified update path from a TLE extension. However, if the update path doesn't exist, this function doesn't raise an error message. Instead, the function returns `false`.
### Function prototype
```
pgtle.uninstall_update_path_if_exists(extname text, fromvers text, tovers text)
```
### Role
`pgtle_admin`
### Arguments
+ `extname` – The name of the TLE extension. This value is used when calling `CREATE EXTENSION`.
+ `fromvers` – The source version of the TLE extension used on the update path.
+ `tovers` – The destination version of the TLE extension used on the update path.
### Output
+ `true` – The function has successfully updated the path for the TLE extension.
+ `false` – The function wasn't able to update the path for the TLE extension.
### Usage example
```
SELECT * FROM pgtle.uninstall_update_path_if_exists('pg_tle_test', '0.1', '0.2');
```
## pgtle.unregister\$1feature
The `unregister_feature` function provides a way to remove functions that were registered to use `pg_tle` features, such as hooks. For information about registering a feature, see [pgtle.register\$1feature](#pgtle.register_feature).
### Function prototype
```
pgtle.unregister_feature(proc regproc, feature pg_tle_features)
```
### Role
`pgtle_admin`
### Arguments
+ `proc` – The name of a stored function to register with a `pg_tle` feature.
+ `feature` – The name of the `pg_tle` feature to register with the function. For example, `passcheck` is a feature that can be registered for use by the trusted language extensions that you develop. For more information, see [Password-check hook (passcheck)](PostgreSQL_trusted_language_extension-hooks-reference.md#passcheck_hook).
### Output
None.
### Usage example
```
SELECT * FROM pgtle.unregister_feature('pw_hook', 'passcheck');
```
## pgtle.unregister\$1feature\$1if\$1exists
The `unregister_feature` function provides a way to remove functions that were registered to use `pg_tle` features, such as hooks. For more information, see [Using PostgreSQL hooks with your TLE extensions](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md). Returns `true` after successfully unregistering the feature. Returns `false` if the feature wasn't registered.
For information about registering `pg_tle` features for your TLE extensions, see [pgtle.register\$1feature](#pgtle.register_feature).
### Function prototype
```
pgtle.unregister_feature_if_exists('proc regproc', 'feature pg_tle_features')
```
### Role
`pgtle_admin`
### Arguments
+ `proc` – The name of the stored function that was registered to include a `pg_tle` feature.
+ `feature` – The name of the `pg_tle` feature that was registered with the trusted language extension.
### Output
Returns `true` or `false`, as follows.
+ `true` – The function has successfully unregistered the feature from extension.
+ `false` – The function wasn't able to unregister the feature from the TLE extension.
### Usage example
```
SELECT * FROM pgtle.unregister_feature_if_exists('pw_hook', 'passcheck');
```
# Hooks reference for Trusted Language Extensions for PostgreSQL
Trusted Language Extensions for PostgreSQL supports PostgreSQL hooks. A *hook* is an internal callback mechanism available to developers for extending PostgreSQL's core functionality. By using hooks, developers can implement their own functions or procedures for use during various database operations, thereby modifying PostgreSQL's behavior in some way. For example, you can use a `passcheck` hook to customize how PostgreSQL handles the passwords supplied when creating or changing passwords for users (roles).
View the following documentation to learn about the passcheck hook available for your TLE extensions. To learn more about the available hooks including the client authentication hook, see [Trusted Language Extensions hooks](https://github.com/aws/pg_tle/blob/main/docs/04_hooks.md).
## Password-check hook (passcheck)
The `passcheck` hook is used to customize PostgreSQL behavior during the password-checking process for the following SQL commands and `psql` metacommand.
+ `CREATE ROLE username ...PASSWORD` – For more information, see [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) in the PostgreSQL documentation.
+ `ALTER ROLE username...PASSWORD` – For more information, see [ALTER ROLE](https://www.postgresql.org/docs/current/sql-alterrole.html) in the PostgreSQL documentation.
+ `\password username` – This interactive `psql` metacommand securely changes the password for the specified user by hashing the password before transparently using the `ALTER ROLE ... PASSWORD` syntax. The metacommand is a secure wrapper for the `ALTER ROLE ... PASSWORD` command, thus the hook applies to the behavior of the `psql` metacommand.
For an example, see [Password-check hook code listing](PostgreSQL_trusted_language_extension.overview.tles-and-hooks.md#PostgreSQL_trusted_language_extension-example-hook_code_listing).
**Contents**
+ [Function prototype](#passcheck_hook-prototype)
+ [Arguments](#passcheck_hook-arguments)
+ [Configuration](#passcheck_hook-configuration)
+ [Usage notes](#passcheck_hook-usage)
### Function prototype
```
passcheck_hook(username text, password text, password_type pgtle.password_types, valid_until timestamptz, valid_null boolean)
```
### Arguments
A `passcheck` hook function takes the following arguments.
+ `username` – The name (as text) of the role (username) that's setting a password.
+ `password` – The plaintext or hashed password. The password entered should match the type specified in `password_type`.
+ `password_type` – Specify the `pgtle.password_type` format of the password. This format can be one of the following options.
+ `PASSWORD_TYPE_PLAINTEXT` – A plaintext password.
+ `PASSWORD_TYPE_MD5` – A password that's been hashed using MD5 (message digest 5) algorithm.
+ `PASSWORD_TYPE_SCRAM_SHA_256` – A password that's been hashed using SCRAM-SHA-256 algorithm.
+ `valid_until` – Specify the time when the password becomes invalid. This argument is optional. If you use this argument, specify the time as a `timestamptz` value.
+ `valid_null` – If this Boolean is set to `true`, the `valid_until` option is set to `NULL`.
### Configuration
The function `pgtle.enable_password_check` controls whether the passcheck hook is active. The passcheck hook has three possible settings.
+ `off` – Turns off the `passcheck` password-check hook. This is the default value.
+ `on` – Turns on the `passcode` password-check hook so that passwords are checked against the table.
+ `require` – Requires a password check hook to be defined.
### Usage notes
To turn the `passcheck` hook on or off, you need to modify the custom DB parameter group for the writer instance of your Aurora PostgreSQL DB cluster.
For Linux, macOS, or Unix:
```
aws rds modify-db-parameter-group \
--region aws-region \
--db-parameter-group-name your-custom-parameter-group \
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
For Windows:
```
aws rds modify-db-parameter-group ^
--region aws-region ^
--db-parameter-group-name your-custom-parameter-group ^
--parameters "ParameterName=pgtle.enable_password_check,ParameterValue=on,ApplyMethod=immediate"
```
# Amazon Aurora PostgreSQL reference
In the following topics, you can find information about collations, functions, parameters, and wait events in Amazon Aurora PostgreSQL.
**Topics**
+ [Aurora PostgreSQL collations for EBCDIC and other mainframe migrations](#AuroraPostgreSQL.Reference.Collations.mainframe.migration)
+ [Collations supported in Aurora PostgreSQL](PostgreSQL-Collations.md)
+ [Aurora PostgreSQL functions reference](Appendix.AuroraPostgreSQL.Functions.md)
+ [Amazon Aurora PostgreSQL parameters](AuroraPostgreSQL.Reference.ParameterGroups.md)
+ [Amazon Aurora PostgreSQL wait events](AuroraPostgreSQL.Reference.Waitevents.md)
## Aurora PostgreSQL collations for EBCDIC and other mainframe migrations
Migrating mainframe applications to new platforms such as AWS ideally preserves application behavior. To preserve application behavior on a new platform exactly as it was on the mainframe requires that migrated data be collated using the same collation and sorting rules. For example, many Db2 migration solutions shift null values to u0180 (Unicode position 0180), so these collations sort u0180 first. This is one example of how collations can vary from their mainframe source and why it's necessary to choose a collation that better maps to the original EBCDIC collation.
Aurora PostgreSQL 14.3 and higher versions provide many ICU and EBCDIC collations to support such migration to AWS using the AWS Mainframe Modernization service. To learn more about this service, see [What is AWS Mainframe Modernization?](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html)
In the following table, you can find Aurora PostgreSQL–provided collations. These collations follow EBCDIC rules and ensure that mainframe applications function the same on AWS as they did in the mainframe environment. The collation name includes the relevant code page, (cp*nnnn*), so that you can choose the appropriate collation for your mainframe source. For example, use `en-US-cp037-x-icu` for to achieve the collation behavior for EBCDIC data that originated from a mainframe application that used code page 037.
| EBCDIC collations | AWS Blu Age collations | AWS Micro Focus collations |
| --- | --- | --- |
| da-DK-cp1142-x-icu | da-DK-cp1142b-x-icu | da-DK-cp1142m-x-icu |
| da-DK-cp277-x-icu | da-DK-cp277b-x-icu | – |
| de-DE-cp1141-x-icu | de-DE-cp1141b-x-icu | de-DE-cp1141m-x-icu |
| de-DE-cp273-x-icu | de-DE-cp273b-x-icu | – |
| en-GB-cp1146-x-icu | en-GB-cp1146b-x-icu | en-GB-cp1146m-x-icu |
| en-GB-cp285-x-icu | en-GB-cp285b-x-icu | – |
| en-US-cp037-x-icu | en-US-cp037b-x-icu | – |
| en-US-cp1140-x-icu | en-US-cp1140b-x-icu | en-US-cp1140m-x-icu |
| es-ES-cp1145-x-icu | es-ES-cp1145b-x-icu | es-ES-cp1145m-x-icu |
| es-ES-cp284-x-icu | es-ES-cp284b-x-icu | – |
| fi-FI-cp1143-x-icu | fi-FI-cp1143b-x-icu | fi-FI-cp1143m-x-icu |
| fi-FI-cp278-x-icu | fi-FI-cp278b-x-icu | – |
| fr-FR-cp1147-x-icu | fr-FR-cp1147b-x-icu | fr-FR-cp1147m-x-icu |
| fr-FR-cp297-x-icu | fr-FR-cp297b-x-icu | – |
| it-IT-cp1144-x-icu | it-IT-cp1144b-x-icu | it-IT-cp1144m-x-icu |
| it-IT-cp280-x-icu | it-IT-cp280b-x-icu | – |
| nl-BE-cp1148-x-icu | nl-BE-cp1148b-x-icu | nl-BE-cp1148m-x-icu |
| nl-BE-cp500-x-icu | nl-BE-cp500b-x-icu | – |
To learn more about AWS Blu Age, see [Tutorial: Managed Runtime for AWS Blu Age](https://docs.aws.amazon.com/m2/latest/userguide/tutorial-runtime-ba.html) in the *AWS Mainframe Modernization User Guide*.
For more information about working with AWS Micro Focus, see [Tutorial: Managed Runtime for Micro Focus](https://docs.aws.amazon.com/m2/latest/userguide/tutorial-runtime.html) in the *AWS Mainframe Modernization User Guide*.
For more information about managing collations in PostgreSQL, see [Collation Support](https://www.postgresql.org/docs/current/collation.html) in the PostgreSQL documentation.
# Collations supported in Aurora PostgreSQL
Collations are set of rules that determine how character strings stored in the database are sorted and compared. Collations play a fundamental role in the computer system and are included as part of the operating system. Collations change over time when new characters are added to languages or when ordering rules change.
Collation libraries define specific rules and algorithms for a collation. The most popular collation libraries used within PostgreSQL are GNU C (glibc) and Internationalization components for Unicode (ICU). By default, Aurora PostgreSQL uses the glibc collation that includes unicode character sort orders for multi-byte character sequences.
When you create a new Aurora PostgreSQL DB cluster, it checks the operating system for the available collation. The PostgreSQL parameters of the `CREATE DATABASE` command `LC_COLLATE` and `LC_CTYPE` are used to specify a collation, which stands as the default collation in that database. Alternatively, you can also use the `LOCALE` parameter in `CREATE DATABASE` to set these parameters. This determines the default collation for character strings in the database and the rules for classifying characters as letters, numbers, or symbols. You can also choose a collation to use on a column, index, or on a query.
Aurora PostgreSQL depends on the glibc library in the operating system for collation support. Aurora PostgreSQL instance is periodically updated with the latest versions of the operating system. These updates sometimes include a newer version of the glibc library. Rarely, newer versions of glibc change the sort order or collation of some characters, which can cause the data to sort differently or produce invalid index entries. If you discover sort order issues for collation during an update, you might need to rebuild the indexes.
To reduce the possible impacts of the glibc updates, Aurora PostgreSQL now includes an independent default collation library. This collation library is available in Aurora PostgreSQL 14.6, 13.9, 12.13, 11.18 and newer minor version releases. It is compatible with glibc 2.26-59.amzn2, and provides sort order stability to prevent incorrect query results.
# Aurora PostgreSQL functions reference
Following, you can find a list of Aurora PostgreSQL functions that are available for your Aurora DB clusters that run the Aurora PostgreSQL-Compatible Edition DB engine. These Aurora PostgreSQL functions are in addition to the standard PostgreSQL functions. For more information about standard PostgreSQL functions, see [PostgreSQL–Functions and Operators](https://www.postgresql.org/docs/current/functions.html).
## Overview
You can use the following functions for Amazon RDS DB instances running Aurora PostgreSQL:
+ [aurora\$1db\$1instance\$1identifier](aurora_db_instance_identifier.md)
+ [aurora\$1ccm\$1status](aurora_ccm_status.md)
+ [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md)
+ [aurora\$1global\$1db\$1status](aurora_global_db_status.md)
+ [aurora\$1list\$1builtins](aurora_list_builtins.md)
+ [aurora\$1replica\$1status](aurora_replica_status.md)
+ [aurora\$1stat\$1activity](aurora_stat_activity.md)
+ [aurora\$1stat\$1backend\$1waits](aurora_stat_backend_waits.md)
+ [aurora\$1stat\$1bgwriter](aurora_stat_bgwriter.md)
+ [aurora\$1stat\$1database](aurora_stat_database.md)
+ [aurora\$1stat\$1dml\$1activity](aurora_stat_dml_activity.md)
+ [aurora\$1stat\$1get\$1db\$1commit\$1latency](aurora_stat_get_db_commit_latency.md)
+ [aurora\$1stat\$1logical\$1wal\$1cache](aurora_stat_logical_wal_cache.md)
+ [aurora\$1stat\$1memctx\$1usage](aurora_stat_memctx_usage.md)
+ [aurora\$1stat\$1optimized\$1reads\$1cache](aurora_stat_optimized_reads_cache.md)
+ [aurora\$1stat\$1plans](aurora_stat_plans.md)
+ [aurora\$1stat\$1reset\$1wal\$1cache](aurora_stat_reset_wal_cache.md)
+ [aurora\$1stat\$1statements](aurora_stat_statements.md)
+ [aurora\$1stat\$1system\$1waits](aurora_stat_system_waits.md)
+ [aurora\$1stat\$1wait\$1event](aurora_stat_wait_event.md)
+ [aurora\$1stat\$1wait\$1type](aurora_stat_wait_type.md)
+ [aurora\$1version](aurora_version.md)
+ [aurora\$1volume\$1logical\$1start\$1lsn](aurora_volume_logical_start_lsn.md)
+ [aurora\$1wait\$1report](aurora_wait_report.md)
# aurora\$1db\$1instance\$1identifier
Reports the name of the DB instance name to which you're connected.
## Syntax
```
aurora_db_instance_identifier()
```
## Arguments
None
## Return type
VARCHAR string
## Usage notes
This function displays the name of Aurora PostgreSQL-Compatible Edition cluster's DB instance for your database client or application connection.
This function is available starting with the release of Aurora PostgreSQL versions 13.7, 12.11, 11.16, 10.21 and for all other later versions.
## Examples
The following example shows results of calling the `aurora_db_instance_identifier` function.
```
=> SELECT aurora_db_instance_identifier();
aurora_db_instance_identifier
-------------------------------
test-my-instance-name
```
You can join the results of this function with the `aurora_replica_status` function to obtain details about the DB instance for your connection. The [aurora\$1replica\$1status](aurora_replica_status.md) alone doesn't provide show you which DB instance you're using. The following example shows you how.
```
=> SELECT *
FROM aurora_replica_status() rt,
aurora_db_instance_identifier() di
WHERE rt.server_id = di;
-[ RECORD 1 ]----------------------+-----------------------
server_id | test-my-instance-name
session_id | MASTER_SESSION_ID
durable_lsn | 88492069
highest_lsn_rcvd |
current_read_lsn |
cur_replay_latency_in_usec |
active_txns |
is_current | t
last_transport_error | 0
last_error_timestamp |
last_update_timestamp | 2022-06-03 11:18:25+00
feedback_xmin |
feedback_epoch |
replica_lag_in_msec |
log_stream_speed_in_kib_per_second | 0
log_buffer_sequence_number | 0
oldest_read_view_trx_id |
oldest_read_view_lsn |
pending_read_ios | 819
```
# aurora\$1ccm\$1status
Displays the status of cluster cache manager.
## Syntax
```
aurora_ccm_status()
```
## Arguments
None.
## Return type
SETOF record with the following columns:
+ `buffers_sent_last_minute` – The number of buffers sent to the designated reader in the past minute.
+ `buffers_found_last_minute` – The number of frequently accessed buffers identified during the past minute.
+ `buffers_sent_last_scan` – The number of buffers sent to the designated reader during the last complete scan of the buffer cache.
+ `buffers_found_last_scan` – The number of frequently accessed buffers sent during the last complete scan of the buffer cache. Buffers that are already cached on the designated reader aren't sent.
+ `buffers_sent_current_scan` – The number of buffers sent during the current scan.
+ `buffers_found_current_scan` – The number of frequently accessed buffers that were identified in the current scan.
+ `current_scan_progress` – The number of buffers visited so far during the current scan.
## Usage notes
You can use this function to check and monitor the cluster cache management (CCM) feature. This function works only if CCM is active on your Aurora PostgreSQL DB cluster. To use this function you connect to the Write DB instance on your Aurora PostgreSQL DB cluster.
You turn on CCM for an Aurora PostgreSQL DB cluster by setting the `apg_ccm_enabled` to 1 in the cluster's custom DB cluster parameter group. To learn how, see [Configuring cluster cache management](AuroraPostgreSQL.cluster-cache-mgmt.md#AuroraPostgreSQL.cluster-cache-mgmt.Configure).
Cluster cache management is active on an Aurora PostgreSQL DB cluster when the cluster has an Aurora Reader instance configured as follows:
+ The Aurora Reader instance uses same DB instance class type and size as the cluster's Writer instance.
+ The Aurora Reader instance is configured as Tier-0 for the cluster. If the cluster has more than one Reader, this is its only Tier-0 Reader.
Setting more than one Reader to Tier-0 disables CCM. When CCM is disabled, calling this function returns the following error message:
```
ERROR: Cluster Cache Manager is disabled
```
You can also the PostgreSQL pg\$1buffercache extension to analyze the buffer cache. For more information, see [pg\$1buffercache](https://www.postgresql.org/docs/current/pgbuffercache.html) in the PostgreSQL documentation.
For more information, see [Introduction to Aurora PostgreSQL cluster cache management](https://aws.amazon.com/blogs/database/introduction-to-aurora-postgresql-cluster-cache-management/).
## Examples
The following example shows the results of calling the `aurora_ccm_status` function. This first example shows CCM statistics.
```
=> SELECT * FROM aurora_ccm_status();
buffers_sent_last_minute | buffers_found_last_minute | buffers_sent_last_scan | buffers_found_last_scan | buffers_sent_current_scan | buffers_found_current_scan | current_scan_progress
--------------------------+---------------------------+------------------------+-------------------------+---------------------------+----------------------------+-----------------------
2242000 | 2242003 | 17920442 | 17923410 | 14098000 | 14100964 | 15877443
```
For more complete detail, you can use expanded display, as shown following:
```
\x
Expanded display is on.
SELECT * FROM aurora_ccm_status();
[ RECORD 1 ]-----------------------+---------
buffers_sent_last_minute | 2242000
buffers_found_last_minute | 2242003
buffers_sent_last_scan | 17920442
buffers_found_last_scan | 17923410
buffers_sent_current_scan | 14098000
buffers_found_current_scan | 14100964
current_scan_progress | 15877443
```
This example shows how to check warm rate and warm percentage.
```
=> SELECT buffers_sent_last_minute * 8/60 AS warm_rate_kbps,
100 * (1.0-buffers_sent_last_scan/buffers_found_last_scan) AS warm_percent
FROM aurora_ccm_status ();
warm_rate_kbps | warm_percent
----------------+--------------
16523 | 100.0
```
# aurora\$1global\$1db\$1instance\$1status
Displays the status of all Aurora instances, including replicas in an Aurora global DB cluster.
## Syntax
```
aurora_global_db_instance_status()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ `server_id` – The identifier of the DB instance.
+ `session_id` – A unique identifier for the current session. A value of `MASTER_SESSION_ID` identifies the Writer (primary) DB instance.
+ `aws_region` – The AWS Region in which this global DB instance runs. For a list of Regions, see [Region availability](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability).
+ `durable_lsn` – The log sequence number (LSN) made durable in storage. A log sequence number (LSN) is a unique sequential number that identifies a record in the database transaction log. LSNs are ordered such that a larger LSN represents a later transaction.
+ `highest_lsn_rcvd` – The highest LSN received by the DB instance from the writer DB instance.
+ `feedback_epoch` – The epoch that the DB instance uses when it generates hot standby information. A *hot standby* is a DB instance that supports connections and queries while the primary DB is in recovery or standby mode. The hot standby information includes the epoch (point in time) and other details about the DB instance that's being used as a hot standby. For more information, see [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) in the PostgreSQL documentation.
+ `feedback_xmin` – The minimum (oldest) active transaction ID used by the DB instance.
+ `oldest_read_view_lsn` – The oldest LSN used by the DB instance to read from storage.
+ `visibility_lag_in_msec` – How far this DB instance is lagging behind the writer DB instance in milliseconds.
## Usage notes
This function shows replication statistics for an Aurora DB cluster. For each Aurora PostgreSQL DB instance in the cluster, the function shows a row of data that includes any cross-Region replicas in a global database configuration.
You can run this function from any instance in an Aurora PostgreSQL DB cluster or an Aurora PostgreSQL global database. The function returns details about lag for all replica instances.
To learn more about monitoring lag using this function (`aurora_global_db_instance_status`) or by using using `aurora_global_db_status`, see [Monitoring Aurora PostgreSQL-based global databases](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres).
For more information about Aurora global databases, see [Overview of Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
To get started with Aurora global databases, see [Getting started with Amazon Aurora Global Database](aurora-global-database-getting-started.md) or see [Amazon Aurora FAQs](https://aws.amazon.com/rds/aurora/faqs/).
## Examples
This example shows cross-Region instance stats.
```
=> SELECT *
FROM aurora_global_db_instance_status();
server_id | session_id | aws_region | durable_lsn | highest_lsn_rcvd | feedback_epoch | feedback_xmin | oldest_read_view_lsn | visibility_lag_in_msec
------------------------------------------+--------------------------------------+--------------+-------------+------------------+----------------+---------------+----------------------+------------------------
db-119-001-instance-01 | MASTER_SESSION_ID | eu-west-1 | 2534560273 | [NULL] | [NULL] | [NULL] | [NULL] | [NULL]
db-119-001-instance-02 | 4ecff34d-d57c-409c-ba28-278b31d6fc40 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-03 | 3e8a20fc-be86-43d5-95e5-bdf19d27ad6b | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560266 | 6
db-119-001-instance-04 | fc1b0023-e8b4-4361-bede-2a7e926cead6 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-instance-05 | 30319b74-3f08-4e13-9728-e02aa1aa8649 | eu-west-1 | 2534560266 | 2534560273 | 0 | 19669196 | 2534560254 | 23
db-119-001-global-instance-1 | a331ffbb-d982-49ba-8973-527c96329c60 | eu-central-1 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 996
db-119-001-global-instance-1 | e0955367-7082-43c4-b4db-70674064a9da | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 14
db-119-001-global-instance-1-eu-west-2a | 1248dc12-d3a4-46f5-a9e2-85850491a897 | eu-west-2 | 2534560254 | 2534560266 | 0 | 19669196 | 2534560247 | 0
```
This example shows how to check global replica lag in milliseconds.
```
=> SELECT CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
aws_region,
server_id,
visibility_lag_in_msec
FROM aurora_global_db_instance_status()
ORDER BY 1, 2, 3;
global_role | aws_region | server_id | visibility_lag_in_msec
-------------+--------------+-----------------------------------------+------------------------
Primary | eu-west-1 | db-119-001-instance-01 | [NULL]
Secondary | eu-central-1 | db-119-001-global-instance-1 | 13
Secondary | eu-west-1 | db-119-001-instance-02 | 10
Secondary | eu-west-1 | db-119-001-instance-03 | 9
Secondary | eu-west-1 | db-119-001-instance-04 | 2
Secondary | eu-west-1 | db-119-001-instance-05 | 18
Secondary | eu-west-2 | db-119-001-global-instance-1 | 14
Secondary | eu-west-2 | db-119-001-global-instance-1-eu-west-2a | 13
```
This example shows how to check min, max and average lag per AWS Region from the global database configuration.
```
=> SELECT 'Secondary' global_role,
aws_region,
min(visibility_lag_in_msec) min_lag_in_msec,
max(visibility_lag_in_msec) max_lag_in_msec,
round(avg(visibility_lag_in_msec),0) avg_lag_in_msec
FROM aurora_global_db_instance_status()
WHERE aws_region NOT IN (SELECT aws_region
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID')
GROUP BY aws_region
UNION ALL
SELECT 'Primary' global_role,
aws_region,
NULL,
NULL,
NULL
FROM aurora_global_db_instance_status()
WHERE session_id='MASTER_SESSION_ID'
ORDER BY 1, 5;
global_role | aws_region | min_lag_in_msec | max_lag_in_msec | avg_lag_in_msec
------------+--------------+-----------------+-----------------+-----------------
Primary | eu-west-1 | [NULL] | [NULL] | [NULL]
Secondary | eu-central-1 | 133 | 133 | 133
Secondary | eu-west-2 | 0 | 495 | 248
```
# aurora\$1global\$1db\$1status
Displays information about various aspects of Aurora global database lag, specifically, lag of the underlying Aurora storage (so called durability lag) and lag between the recovery point objective (RPO).
## Syntax
```
aurora_global_db_status()
```
## Arguments
None.
## Return type
SETOF record with the following columns:
+ `aws_region` – The AWS Region that this DB cluster is in. For a complete listing of AWS Regions by engine, see [Regions and Availability Zones](Concepts.RegionsAndAvailabilityZones.md).
+ `highest_lsn_written` – The highest log sequence number (LSN) that currently exists on this DB cluster. A log sequence number (LSN) is a unique sequential number that identifies a record in the database transaction log. LSNs are ordered such that a larger LSN represents a later transaction.
+ `durability_lag_in_msec` – The difference in the timestamp values between the `highest_lsn_written` on a secondary DB cluster and the `highest_lsn_written` on the primary DB cluster. A value of -1 identifies the primary DB cluster of the Aurora global database.
+ `rpo_lag_in_msec` – The recovery point objective (RPO) lag. The RPO lag is the time it takes for the most recent user transaction COMMIT to be stored on a secondary DB cluster after it's been stored on the primary DB cluster of the Aurora global database. A value of -1 denotes the primary DB cluster (and thus, lag isn't relevant).
In simple terms, this metric calculates the recovery point objective for each Aurora PostgreSQL DB cluster in the Aurora global database, that is, how much data might be lost if there were an outage. As with lag, RPO is measured in time.
+ `last_lag_calculation_time` – The timestamp that specifies when values were last calculated for `durability_lag_in_msec` and `rpo_lag_in_msec`. A time value such as `1970-01-01 00:00:00+00` means this is the primary DB cluster.
+ `feedback_epoch` – The epoch that the secondary DB cluster uses when it generates hot standby information. A *hot standby* is a DB instance that supports connections and queries while the primary DB is in recovery or standby mode. The hot standby information includes the epoch (point in time) and other details about the DB instance that's being used as a hot standby. For more information, see [Hot Standby](https://www.postgresql.org/docs/current/hot-standby.html) in the PostgreSQL documentation.
+ `feedback_xmin` – The minimum (oldest) active transaction ID used by a secondary DB cluster.
## Usage notes
All currently available Aurora PostgreSQL versions support this function. This function shows replication statistics for an Aurora global database. It shows one row for each DB cluster in an Aurora PostgreSQL global database. You can run this function from any instance in your Aurora PostgreSQL global database.
To evaluate Aurora global database replication lag, which is the visible data lag, see [aurora\$1global\$1db\$1instance\$1status](aurora_global_db_instance_status.md).
To learn more about using `aurora_global_db_status` and `aurora_global_db_instance_status` to monitor Aurora global database lag, see [Monitoring Aurora PostgreSQL-based global databases](aurora-global-database-monitoring.md#aurora-global-database-monitoring.postgres). For more information about Aurora global databases, see [Overview of Amazon Aurora Global Database](aurora-global-database.md#aurora-global-database-overview).
## Examples
This example shows how to display cross-region storage statistics.
```
=> SELECT CASE
WHEN '-1' = durability_lag_in_msec THEN 'Primary'
ELSE 'Secondary'
END AS global_role,
*
FROM aurora_global_db_status();
global_role | aws_region | highest_lsn_written | durability_lag_in_msec | rpo_lag_in_msec | last_lag_calculation_time | feedback_epoch | feedback_xmin
-------------+------------+---------------------+------------------------+-----------------+----------------------------+----------------+---------------
Primary | eu-west-1 | 131031557 | -1 | -1 | 1970-01-01 00:00:00+00 | 0 | 0
Secondary | eu-west-2 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
Secondary | eu-west-3 | 131031554 | 410 | 0 | 2021-06-01 18:59:36.124+00 | 0 | 12640
```
# aurora\$1list\$1builtins
Lists all available Aurora PostgreSQL built-in functions, along with brief descriptions and function details.
## Syntax
```
aurora_list_builtins()
```
## Arguments
None
## Return type
SETOF record
## Examples
The following example shows results from calling the `aurora_list_builtins` function.
```
=> SELECT *
FROM aurora_list_builtins();
Name | Result data type | Argument data types | Type | Volatility | Parallel | Security | Description
-----------------------------------+------------------+----------------------------------------------------------+------+------------+------------+----------+---------------------------------------------------------------------
aurora_version | text | | func | stable | safe | invoker | Amazon Aurora PostgreSQL-Compatible Edition version string
aurora_stat_wait_type | SETOF record | OUT type_id smallint, OUT type_name text | func | volatile | restricted | invoker | Lists all supported wait types
aurora_stat_wait_event | SETOF record | OUT type_id smallint, OUT event_id integer, OUT event_na.| func | volatile | restricted | invoker | Lists all supported wait events
| |.me text | | | | |
aurora_list_builtins | SETOF record | OUT "Name" text, OUT "Result data type" text, OUT "Argum.| func | stable | safe | invoker | Lists all Aurora built-in functions
| |.ent data types" text, OUT "Type" text, OUT "Volatility" .| | | | |
| |.text, OUT "Parallel" text, OUT "Security" text, OUT "Des.| | | | |
| |.cription" text | | | | |
.
.
.
aurora_stat_file | SETOF record | OUT filename text, OUT allocated_bytes bigint, OUT used_.| func | stable | safe | invoker | Lists all files present in Aurora storage
| |.bytes bigint | | | | |
aurora_stat_get_db_commit_latency | bigint | oid | func | stable | restricted | invoker | Per DB commit latency in microsecs
```
# aurora\$1replica\$1status
Displays the status of all Aurora PostgreSQL reader nodes.
## Syntax
```
aurora_replica_status()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ `server_id` – The DB instance ID (identifier).
+ `session_id` – A unique identifier for the current session, returned for primary instance and reader instances as follows:
+ For the primary instance, `session_id` is always ``MASTER_SESSION_ID’`.
+ For reader instances, `session_id` is always the `UUID` (universally unique identifier) of the reader instance.
+ `durable_lsn` – The log sequence number (LSN) that's been saved in storage.
+ For the primary volume, the primary volume durable LSN (VDL) that's currently in effect.
+ For any secondary volumes, the VDL of the primary up to which the secondary has successfully been applied.
**Note**
A log sequence number (LSN) is a unique sequential number that identifies a record in the database transaction log. LSNs are ordered such that a larger LSN represents a transaction that's occurred later in the sequence.
+ `highest_lsn_rcvd` – The highest (most recent) LSN received by the DB instance from the writer DB instance.
+ `current_read_lsn` – The LSN of the most recent snapshot that's been applied to all readers.
+ `cur_replay_latency_in_usec` – The number of microseconds that it's expected to take to replay the log on the secondary.
+ `active_txns` – The number of currently active transactions.
+ `is_current` – Not used.
+ `last_transport_error` – Last replication error code.
+ `last_error_timestamp` – Timestamp of last replication error.
+ `last_update_timestamp` – Timestamp of last update to replica status. From Aurora PostgreSQL 13.9, the `last_update_timestamp` value for the DB instance that you are connected to is set to `NULL`.
+ `feedback_xmin` – The hot standby feedback\$1xmin of the replica. The minimum (oldest) active transaction ID used by the DB instance.
+ `feedback_epoch` – The epoch the DB instance uses when it generates hot standby information.
+ `replica_lag_in_msec` – Time that reader instance lags behind writer instance, in milliseconds.
+ `log_stream_speed_in_kib_per_second` – The log stream throughput in kilobytes per second.
+ `log_buffer_sequence_number` – The log buffer sequence number.
+ `oldest_read_view_trx_id` – Not used.
+ `oldest_read_view_lsn` – The oldest LSN used by the DB instance to read from storage.
+ `pending_read_ios` – The outstanding page reads that are still pending on replica.
+ `read_ios` – The total number of page reads on replica.
+ `iops` – Not used.
+ `cpu` – CPU usage of the Aurora Storage Daemon for each node in the cluster. For information about CPU usage by the instance, see [Instance-level metrics for Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
## Usage notes
All currently available Aurora PostgreSQL versions support this function. The `aurora_replica_status` function returns values from an Aurora PostgreSQL DB cluster's replica status manager. You can use this function to obtain information about the status of replication on your Aurora PostgreSQL DB cluster, including metrics for all DB instances in your Aurora DB cluster. For example, you can do the following:
+ **Get information about the type of instance (writer, reader) in the Aurora PostgreSQL DB cluster** – You can obtain this information by checking the values of the following columns:
+ `server_id` – Contains the name of the instance that you specified when you created the instance. In some cases, such as for the primary (writer) instance, the name is typically created for you by appending *-instance-1* to the name that you create for your Aurora PostgreSQL DB cluster.
+ `session_id` – The `session_id` field indicates whether the instance is a reader or a writer. For a writer instance, `session_id` is always set to `"MASTER_SESSION_ID"`. For a reader instance, `session_id` is set to the `UUID` of the specific reader.
+ **Diagnose common replication issues, such as replica lag** – Replica lag is the time in milliseconds that the page cache of a reader instance is behind that of the writer instance. This lag occurs because Aurora clusters use asynchronous replication, as described in [Replication with Amazon Aurora](Aurora.Replication.md). It's shown in the `replica_lag_in_msec` column in the results returned by this function. Lag can also occur when a query is cancelled due to conflicts with recovery on a standby server. You can check `pg_stat_database_conflicts()` to verify that such a conflict is causing the replica lag (or not). For more information, see [The Statistics Collector](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-CONFLICTS-VIEW) in the *PostgreSQL documentation*. To learn more about high availability and replication, see [Amazon Aurora FAQs](https://aws.amazon.com/rds/aurora/faqs/#High_Availability_and_Replication).
Amazon CloudWatch stores `replica_lag_in_msec` results over time, as the `AuroraReplicaLag` metric. For information about using CloudWatch metrics for Aurora, see [Monitoring Amazon Aurora metrics with Amazon CloudWatch](monitoring-cloudwatch.md)
To learn more about troubleshooting Aurora read replicas and restarts, see [Why did my Amazon Aurora read replica fall behind and restart?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-read-replica-restart/) in the [AWS Support Center](https://console.aws.amazon.com/support/home#/).
## Examples
The following example shows how to get the replication status of all instances in an Aurora PostgreSQL DB cluster:
```
=> SELECT *
FROM aurora_replica_status();
```
The following example shows the writer instance in the `docs-lab-apg-main` Aurora PostgreSQL DB cluster:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id = 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-01 | writer
```
The following example example lists all reader instances in a cluster:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role
FROM aurora_replica_status()
WHERE session_id <> 'MASTER_SESSION_ID';
server_id | instance_role
------------------------+---------------
db-119-001-instance-02 | reader
db-119-001-instance-03 | reader
db-119-001-instance-04 | reader
db-119-001-instance-05 | reader
(4 rows)
```
The following example lists all instances, how far each instance is lagging behind the writer, and how long since the last update:
```
=> SELECT server_id,
CASE
WHEN 'MASTER_SESSION_ID' = session_id THEN 'writer'
ELSE 'reader'
END AS instance_role,
replica_lag_in_msec AS replica_lag_ms,
round(extract (epoch FROM (SELECT age(clock_timestamp(), last_update_timestamp))) * 1000) AS last_update_age_ms
FROM aurora_replica_status()
ORDER BY replica_lag_in_msec NULLS FIRST;
server_id | instance_role | replica_lag_ms | last_update_age_ms
------------------------+---------------+----------------+--------------------
db-124-001-instance-03 | writer | [NULL] | 1756
db-124-001-instance-01 | reader | 13 | 1756
db-124-001-instance-02 | reader | 13 | 1756
(3 rows)
```
# aurora\$1stat\$1activity
Returns one row per server process, showing information related to the current activity of that process.
## Syntax
```
aurora_stat_activity();
```
## Arguments
None
## Return type
Returns one row per server process. In additional to `pg_stat_activity` columns, the following field is added:
+ planid – plan identifier
## Usage notes
A supplementary view to `pg_stat_activity` returning the same columns with an additional `plan_id` column which shows the current query execution plan.
`aurora_compute_plan_id` must be enabled for the view to return a plan\$1id.
This function is available from Aurora PostgreSQL versions 14.10, 15.5, and for all other later versions.
## Examples
The example query below aggregates the top load by query\$1id and plan\$1id.
```
db1=# select count(*), query_id, plan_id
db1-# from aurora_stat_activity() where state = 'active'
db1-# and pid <> pg_backend_pid()
db1-# group by query_id, plan_id
db1-# order by 1 desc;
count | query_id | plan_id
-------+----------------------+-------------
11 | -5471422286312252535 | -2054628807
3 | -6907107586630739258 | -815866029
1 | 5213711845501580017 | 300482084
(3 rows)
```
If the plan used for query\$1id changes, a new plan\$1id will be reported by aurora\$1stat\$1activity.
```
count | query_id | plan_id
-------+----------------------+-------------
10 | -5471422286312252535 | 1602979607
1 | -6907107586630739258 | -1809935983
1 | -2446282393000597155 | -207532066
(3 rows)
```
# aurora\$1stat\$1backend\$1waits
Displays statistics for wait activity for a specific backend process.
## Syntax
```
aurora_stat_backend_waits(pid)
```
## Arguments
`pid` – The ID for the backend process. You can obtain process IDs by using the `pg_stat_activity` view.
## Return type
SETOF record with the following columns:
+ `type_id` – A number that denotes the type of wait event, such as `1` for a lightweight lock (`LWLock`), `3` for a lock, or `6` for a client session, to name some examples. These values become meaningful when you join the results of this function with columns from `aurora_stat_wait_type` function, as shown in the [Examples](#aurora_stat_backend_waits-examples).
+ `event_id` – An identifying number for the wait event. Join this value with the columns from `aurora_stat_wait_event` to obtain meaningful event names.
+ `waits` – A count of the number of waits accumulated for the specified process ID.
+ `wait_time` – Wait time in milliseconds.
## Usage notes
You can use this function to analyze specific backend (session) wait events that occurred since a connection opened. To get more meaningful information about wait event names and types, you can combine this function `aurora_stat_wait_type` and `aurora_stat_wait_event`, by using JOIN as shown in the examples.
## Examples
This example shows all waits, types, and event names for a backend process ID 3027.
```
=> SELECT type_name, event_name, waits, wait_time
FROM aurora_stat_backend_waits(3027)
NATURAL JOIN aurora_stat_wait_type()
NATURAL JOIN aurora_stat_wait_event();
type_name | event_name | waits | wait_time
-----------+------------------------+-------+------------
LWLock | ProcArrayLock | 3 | 27
LWLock | wal_insert | 423 | 16336
LWLock | buffer_content | 11840 | 1033634
LWLock | lock_manager | 23821 | 5664506
Lock | tuple | 10258 | 152280165
Lock | transactionid | 78340 | 1239808783
Client | ClientRead | 34072 | 17616684
IO | ControlFileSyncUpdate | 2 | 0
IO | ControlFileWriteUpdate | 4 | 32
IO | RelationMapRead | 2 | 795
IO | WALWrite | 36666 | 98623
IO | XactSync | 4867 | 7331963
```
This example shows current and cumulative wait types and wait events for all active sessions (`pg_stat_activity state <> 'idle'`) (but without the current session that's invoking the function (`pid <> pg_backend_pid()`).
```
=> SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+----------+----------+-------------------+--------------------+---------------+-----------+------------------------+-------+-----------
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1937 | 29975
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22903 | 760498
30099 | postgres | pgbench | Lock | transactionid | active | LWLock | lock_manager | 10012 | 223207
30099 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 20315 | 63081529
.
.
.
30099 | postgres | pgbench | Lock | transactionid | active | IO | WALWrite | 93293 | 237440
30099 | postgres | pgbench | Lock | transactionid | active | IO | XactSync | 13010 | 19525143
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | ProcArrayLock | 6 | 53
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | wal_insert | 1913 | 25450
30100 | postgres | pgbench | Lock | transactionid | active | LWLock | buffer_content | 22874 | 778005
.
.
.
30109 | postgres | pgbench | IO | XactSync | active | LWLock | ProcArrayLock | 3 | 71
30109 | postgres | pgbench | IO | XactSync | active | LWLock | wal_insert | 1940 | 27741
30109 | postgres | pgbench | IO | XactSync | active | LWLock | buffer_content | 22962 | 776352
30109 | postgres | pgbench | IO | XactSync | active | LWLock | lock_manager | 9879 | 218826
30109 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 20401 | 63581306
30109 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 50769 | 211645008
30109 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 89901 | 44192439
```
This example shows current and the top three (3) cumulative wait type and wait events for all active sessions (`pg_stat_activity state <> 'idle'`) excluding current session (`pid <>pg_backend_pid()`).
```
=> SELECT top3.*
FROM (SELECT a.pid,
a.usename,
a.app_name,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time,
RANK() OVER (PARTITION BY pid ORDER BY a.wait_time DESC)
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND state <> 'idle') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we) top3
WHERE RANK <=3;
pid | usename | app_name | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time | rank
-------+----------+----------+-------------------+--------------------+---------------+-----------+-----------------+---------+------------+------
20567 | postgres | psql | CPU | CPU | active | LWLock | wal_insert | 25000 | 67512003 | 1
20567 | postgres | psql | CPU | CPU | active | IO | WALWrite | 3071758 | 1016961 | 2
20567 | postgres | psql | CPU | CPU | active | IO | BufFileWrite | 20750 | 184559 | 3
27743 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237350 | 1265580011 | 1
27743 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93641 | 341472318 | 2
27743 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417556 | 204796837 | 3
.
.
.
27745 | postgres | pgbench | IO | XactSync | active | Lock | transactionid | 238068 | 1265816822 | 1
27745 | postgres | pgbench | IO | XactSync | active | Lock | tuple | 93210 | 338312247 | 2
27745 | postgres | pgbench | IO | XactSync | active | Client | ClientRead | 419157 | 207836533 | 3
27746 | postgres | pgbench | Lock | transactionid | active | Lock | transactionid | 237621 | 1264528811 | 1
27746 | postgres | pgbench | Lock | transactionid | active | Lock | tuple | 93563 | 339799310 | 2
27746 | postgres | pgbench | Lock | transactionid | active | Client | ClientRead | 417304 | 208372727 | 3
```
# aurora\$1stat\$1bgwriter
`aurora_stat_bgwriter` is a statistics view showing information about Optimized Reads cache writes.
## Syntax
```
aurora_stat_bgwriter()
```
## Arguments
None
## Return type
SETOF record with all `pg_stat_bgwriter` columns and the following additional columns. For more information on `pg_stat_bgwriter` columns, see [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-BGWRITER-VIEW).
You can reset stats for this function using `pg_stat_reset_shared("bgwriter")`.
+ `orcache_blks_written` – Total number of optimized reads cache data blocks written.
+ `orcache_blk_write_time` – If `track_io_timing` is enabled, it tracks the total time spent writing optimized reads cache data file blocks, in milliseconds. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
## Usage notes
This function is available in the following Aurora PostgreSQL versions:
+ 15.4 and higher 15 versions
+ 14.9 and higher 14 versions
## Examples
```
=> select * from aurora_stat_bgwriter();
-[ RECORD 1 ]-----------------+-----------
orcache_blks_written | 246522
orcache_blk_write_time | 339276.404
```
# aurora\$1stat\$1database
It carries all columns of pg\$1stat\$1database and adds new columns in the end.
## Syntax
```
aurora_stat_database()
```
## Arguments
None
## Return type
SETOF record with all `pg_stat_database` columns and the following additional columns. For more information on `pg_stat_database` columns, see [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-DATABASE-VIEW).
+ `storage_blks_read` – Total number of shared blocks read from aurora storage in this database.
+ `orcache_blks_hit` – Total number of optimized reads cache hits in this database.
+ `local_blks_read` – Total number of local blocks read in this database.
+ `storage_blk_read_time` – If `track_io_timing` is enabled, it tracks the total time spent reading data file blocks from aurora storage, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time` – If `track_io_timing` is enabled, it tracks the total time spent reading local data file blocks, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time` – If `track_io_timing` is enabled, it tracks the total time spent reading data file blocks from optimized reads cache, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
**Note**
The value of `blks_read` is the sum of `storage_blks_read`, `orcache_blks_hit`, and `local_blks_read`.
The value of `blk_read_time` is the sum of `storage_blk_read_time`, `orcache_blk_read_time`, and `local_blk_read_time`.
## Usage notes
This function is available in the following Aurora PostgreSQL versions:
+ 15.4 and higher 15 versions
+ 14.9 and higher 14 versions
## Examples
The following example shows how it carries all the `pg_stat_database` columns and appends 6 new columns in the end:
```
=> select * from aurora_stat_database() where datid=14717;
-[ RECORD 1 ]------------+------------------------------
datid | 14717
datname | postgres
numbackends | 1
xact_commit | 223
xact_rollback | 4
blks_read | 1059
blks_hit | 11456
tup_returned | 27746
tup_fetched | 5220
tup_inserted | 165
tup_updated | 42
tup_deleted | 91
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
checksum_failures |
checksum_last_failure |
blk_read_time | 3358.689
blk_write_time | 0
session_time | 1076007.997
active_time | 3684.371
idle_in_transaction_time | 0
sessions | 10
sessions_abandoned | 0
sessions_fatal | 0
sessions_killed | 0
stats_reset | 2023-01-12 20:15:17.370601+00
orcache_blks_hit | 425
orcache_blk_read_time | 89.934
storage_blks_read | 623
storage_blk_read_time | 3254.914
local_blks_read | 0
local_blk_read_time | 0
```
# aurora\$1stat\$1dml\$1activity
Reports cumulative activity for each type of data manipulation language (DML) operation on a database in an Aurora PostgreSQL cluster.
## Syntax
```
aurora_stat_dml_activity(database_oid)
```
## Arguments
*database\$1oid*
The object ID (OID) of the database in the Aurora PostgreSQL cluster.
## Return type
SETOF record
## Usage notes
The `aurora_stat_dml_activity` function is only available with Aurora PostgreSQL release 3.1 compatible with PostgreSQL engine 11.6 and later.
Use this function on Aurora PostgreSQL clusters with a large number of databases to identify which databases have more or slower DML activity, or both.
The `aurora_stat_dml_activity` function returns the number of times the operations ran and the cumulative latency in microseconds for SELECT, INSERT, UPDATE, and DELETE operations. The report includes only successful DML operations.
You can reset this statistic by using the PostgreSQL statistics access function `pg_stat_reset`. You can check the last time this statistic was reset by using the `pg_stat_get_db_stat_reset_time` function. For more information about PostgreSQL statistics access functions, see [The Statistics Collector](https://www.postgresql.org/docs/9.1/monitoring-stats.html) in the PostgreSQL documentation.
## Examples
The following example shows how to report DML activity statistics for the connected database.
```
––Define the oid variable from connected database by using \gset
=> SELECT oid,
datname
FROM pg_database
WHERE datname=(select current_database()) \gset
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
178957 | 66684115 | 171065 | 28876649 | 519538 | 1454579206167 | 1 | 53027
–– Showing the same results with expanded display on
=> SELECT *
FROM aurora_stat_dml_activity(:oid);
-[ RECORD 1 ]------------+--------------
select_count | 178957
select_latency_microsecs | 66684115
insert_count | 171065
insert_latency_microsecs | 28876649
update_count | 519538
update_latency_microsecs | 1454579206167
delete_count | 1
delete_latency_microsecs | 53027
```
The following example shows DML activity statistics for all databases in the Aurora PostgreSQL cluster. This cluster has two databases, `postgres` and `mydb`. The comma-separated list corresponds with the `select_count`, `select_latency_microsecs`, `insert_count`, `insert_latency_microsecs`, `update_count`, `update_latency_microsecs`, `delete_count`, and `delete_latency_microsecs` fields.
Aurora PostgreSQL creates and uses a system database named `rdsadmin` to support administrative operations such as backups, restores, health checks, replication, and so on. These DML operations have no impact on your Aurora PostgreSQL cluster.
```
=> SELECT oid,
datname,
aurora_stat_dml_activity(oid)
FROM pg_database;
oid | datname | aurora_stat_dml_activity
-------+----------------+-----------------------------------------------------------------
14006 | template0 | (,,,,,,,)
16384 | rdsadmin | (2346623,1211703821,4297518,817184554,0,0,0,0)
1 | template1 | (,,,,,,,)
14007 | postgres | (178961,66716329,171065,28876649,519538,1454579206167,1,53027)
16401 | mydb | (200246,64302436,200036,107101855,600000,83659417514,0,0)
```
The following example shows DML activity statistics for all databases, organized in columns for better readability.
```
SELECT db.datname,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 1), '()') AS select_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 2), '()') AS select_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 3), '()') AS insert_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 4), '()') AS insert_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 5), '()') AS update_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 6), '()') AS update_latency_microsecs,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 7), '()') AS delete_count,
BTRIM(SPLIT_PART(db.asdmla::TEXT, ',', 8), '()') AS delete_latency_microsecs
FROM (SELECT datname,
aurora_stat_dml_activity(oid) AS asdmla
FROM pg_database
) AS db;
datname | select_count | select_latency_microsecs | insert_count | insert_latency_microsecs | update_count | update_latency_microsecs | delete_count | delete_latency_microsecs
----------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------+--------------+--------------------------
template0 | | | | | | | |
rdsadmin | 4206523 | 2478812333 | 7009414 | 1338482258 | 0 | 0 | 0 | 0
template1 | | | | | | | |
fault_test | 66 | 452099 | 0 | 0 | 0 | 0 | 0 | 0
db_access_test | 1 | 5982 | 0 | 0 | 0 | 0 | 0 | 0
postgres | 42035 | 95179203 | 5752 | 2678832898 | 21157 | 441883182488 | 2 | 1520
mydb | 71 | 453514 | 0 | 0 | 1 | 190 | 1 | 152
```
The following example shows the average cumulative latency (cumulative latency divided by count) for each DML operation for the database with the OID `16401`.
```
=> SELECT select_count,
select_latency_microsecs,
select_latency_microsecs/NULLIF(select_count,0) select_latency_per_exec,
insert_count,
insert_latency_microsecs,
insert_latency_microsecs/NULLIF(insert_count,0) insert_latency_per_exec,
update_count,
update_latency_microsecs,
update_latency_microsecs/NULLIF(update_count,0) update_latency_per_exec,
delete_count,
delete_latency_microsecs,
delete_latency_microsecs/NULLIF(delete_count,0) delete_latency_per_exec
FROM aurora_stat_dml_activity(16401);
-[ RECORD 1 ]------------+-------------
select_count | 451312
select_latency_microsecs | 80205857
select_latency_per_exec | 177
insert_count | 451001
insert_latency_microsecs | 123667646
insert_latency_per_exec | 274
update_count | 1353067
update_latency_microsecs | 200900695615
update_latency_per_exec | 148478
delete_count | 12
delete_latency_microsecs | 448
delete_latency_per_exec | 37
```
# aurora\$1stat\$1get\$1db\$1commit\$1latency
Gets the cumulative commit latency in microseconds for Aurora PostgreSQL databases. *Commit latency* is measured as the time between when a client submits a commit request and when it receives the commit acknowledgement.
## Syntax
```
aurora_stat_get_db_commit_latency(database_oid)
```
## Arguments
*database\$1oid*
The object ID (OID) of the Aurora PostgreSQL database.
## Return type
SETOF record
## Usage notes
Amazon CloudWatch uses this function to calculate the average commit latency. For more information about Amazon CloudWatch metrics and how to troubleshoot high commit latency, see [Viewing metrics in the Amazon RDS console](USER_Monitoring.md) and [Making better decisions about Amazon RDS with Amazon CloudWatch metrics](https://aws.amazon.com/blogs/database/making-better-decisions-about-amazon-rds-with-amazon-cloudwatch-metrics/).
You can reset this statistic by using the PostgreSQL statistics access function `pg_stat_reset`. You can check the last time this statistic was reset by using the `pg_stat_get_db_stat_reset_time` function. For more information about PostgreSQL statistics access functions, see [The Statistics Collector](https://www.postgresql.org/docs/9.1/monitoring-stats.html) in the PostgreSQL documentation.
## Examples
The following example gets the cumulative commit latency for each database in the `pg_database` cluster.
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database;
oid | datname | aurora_stat_get_db_commit_latency
-------+----------------+-----------------------------------
14006 | template0 | 0
16384 | rdsadmin | 654387789
1 | template1 | 0
16401 | mydb | 229556
69768 | postgres | 22011
```
The following example gets the cumulative commit latency for the currently connected database. Before calling the `aurora_stat_get_db_commit_latency` function, the example first uses `\gset` to define a variable for the `oid` argument and sets its value from the connected database.
```
––Get the oid value from the connected database before calling aurora_stat_get_db_commit_latency
=> SELECT oid
FROM pg_database
WHERE datname=(SELECT current_database()) \gset
=> SELECT *
FROM aurora_stat_get_db_commit_latency(:oid);
aurora_stat_get_db_commit_latency
-----------------------------------
1424279160
```
The following example gets the cumulative commit latency for the `mydb` database in the `pg_database` cluster. Then, it resets this statistic by using the `pg_stat_reset` function and shows the results. Finally, it uses the `pg_stat_get_db_stat_reset_time` function to check the last time this statistic was reset.
```
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 3320370
=> SELECT pg_stat_reset();
pg_stat_reset
---------------
=> SELECT oid,
datname,
aurora_stat_get_db_commit_latency(oid)
FROM pg_database
WHERE datname = 'mydb';
oid | datname | aurora_stat_get_db_commit_latency
-------+-----------+-----------------------------------
16427 | mydb | 6
=> SELECT *
FROM pg_stat_get_db_stat_reset_time(16427);
pg_stat_get_db_stat_reset_time
--------------------------------
2021-04-29 21:36:15.707399+00
```
# aurora\$1stat\$1logical\$1wal\$1cache
Shows logical write-ahead log (WAL) cache usage per slot.
## Syntax
```
SELECT * FROM aurora_stat_logical_wal_cache()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ `name` – The name of the replication slot.
+ `active_pid` – ID of the walsender process.
+ `cache_hit` – The total number of wal cache hits since last reset.
+ `cache_miss` – The total number of wal cache misses since last reset.
+ `blks_read` – The total number of wal cache read requests.
+ `hit_rate` – The WAL cache hit rate (cache\$1hit / blks\$1read).
+ `last_reset_timestamp` – Last time that the counter was reset.
## Usage notes
This function is available for the following Aurora PostgreSQL versions.
+ 15.2 and all higher versions
+ 14.7 and higher versions
+ 13.8 and higher versions
+ 12.12 and higher versions
+ 11.17 and higher versions
## Examples
The following example shows two replication slots with only one active. `aurora_stat_logical_wal_cache` function.
```
=> SELECT *
FROM aurora_stat_logical_wal_cache();
name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp
------------+------------+-----------+------------+-----------+----------+-------------------------------
test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39:56.830635+00
test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34:04.036795+00
(2 rows)
```
# aurora\$1stat\$1memctx\$1usage
Reports the memory context usage for each PostgreSQL process.
## Syntax
```
aurora_stat_memctx_usage()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ `pid` – The ID of the process.
+ `name` – The name of the memory context.
+ `allocated` – The number of bytes obtained from the underlying memory subsystem by the memory context.
+ `used` – The number of bytes committed to clients of the memory context.
+ `instances` – The count of currently existing contexts of this type.
## Usage notes
This function displays the memory context usage for each PostgreSQL process. Some processes are labeled `anonymous`. The processes aren't exposed because they contain restricted keywords.
This function is available starting with the following Aurora PostgreSQL versions:
+ 15.3 and higher 15 versions
+ 14.8 and higher 14 versions
+ 13.11 and higher 13 versions
+ 12.15 and higher 12 versions
+ 11.20 and higher 11 versions
## Examples
The following example shows the results of calling the `aurora_stat_memctx_usage` function.
```
=> SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
123864 | Miscellaneous | 19520 | 15064 | 3
123864 | Aurora File Context | 8192 | 616 | 1
123864 | Aurora WAL Context | 8192 | 296 | 1
123864 | CacheMemoryContext | 524288 | 422600 | 1
123864 | Catalog tuple context | 16384 | 13736 | 1
123864 | ExecutorState | 32832 | 28304 | 1
123864 | ExprContext | 8192 | 1720 | 1
123864 | GWAL record construction | 1024 | 832 | 1
123864 | MdSmgr | 8192 | 296 | 1
123864 | MessageContext | 532480 | 353832 | 1
123864 | PortalHeapMemory | 1024 | 488 | 1
123864 | PortalMemory | 8192 | 576 | 1
123864 | printtup | 8192 | 296 | 1
123864 | RelCache hash table entries | 8192 | 8152 | 1
123864 | RowDescriptionContext | 8192 | 1344 | 1
123864 | smgr relation context | 8192 | 296 | 1
123864 | Table function arguments | 8192 | 352 | 1
123864 | TopTransactionContext | 8192 | 632 | 1
123864 | TransactionAbortContext | 32768 | 296 | 1
123864 | WAL record construction | 50216 | 43904 | 1
123864 | hash table | 65536 | 52744 | 6
123864 | Relation metadata | 191488 | 124240 | 87
104992 | Miscellaneous | 9280 | 7728 | 3
104992 | Aurora File Context | 8192 | 376 | 1
104992 | Aurora WAL Context | 8192 | 296 | 1
104992 ||Autovacuum Launcher | 8192 | 296 | 1
104992 | Autovacuum database list | 16384 | 744 | 2
104992 | CacheMemoryContext | 262144 | 140288 | 1
104992 | Catalog tuple context | 8192 | 296 | 1
104992 | GWAL record construction | 1024 | 832 | 1
104992 | MdSmgr | 8192 | 296 | 1
104992 | PortalMemory | 8192 | 296 | 1
104992 | RelCache hash table entries | 8192 | 296 | 1
104992 | smgr relation context | 8192 | 296 | 1
104992 | Autovacuum start worker (tmp) | 8192 | 296 | 1
104992 | TopTransactionContext | 16384 | 592 | 2
104992 | TransactionAbortContext | 32768 | 296 | 1
104992 | WAL record construction | 50216 | 43904 | 1
104992 | hash table | 49152 | 34024 | 4
(39 rows)
```
Some restricted keywords will be hidden and the output will look as follows:
```
postgres=>SELECT *
FROM aurora_stat_memctx_usage();
pid| name | allocated | used | instances
-------+---------------------------------+-----------+---------+-----------
5482 | anonymous | 8192 | 456 | 1
5482 | anonymous | 8192 | 296 | 1
```
# aurora\$1stat\$1optimized\$1reads\$1cache
This function shows tiered cache stats.
## Syntax
```
aurora_stat_optimized_reads_cache()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ `total_size` – Total optimized reads cache size.
+ `used_size` – Used page size in optimized reads cache.
## Usage notes
This function is available in the following Aurora PostgreSQL versions:
+ 15.4 and higher 15 versions
+ 14.9 and higher 14 versions
## Examples
The following example shows the output on a r6gd.8xlarge instance :
```
=> select pg_size_pretty(total_size) as total_size, pg_size_pretty(used_size)
as used_size from aurora_stat_optimized_reads_cache();
total_size | used_size
-----------+-----------
1054 GB | 975 GB
```
# aurora\$1stat\$1plans
Returns a row for every tracked execution plan.
## Syntax
```
aurora_stat_plans(
showtext
)
```
## Arguments
+ showtext – Show the query and plan text. Valid values are NULL, true or false. True will show the query and plan text.
## Return type
Returns a row for each tracked plan that contains all the columns from `aurora_stat_statements` and the following additional columns.
+ planid – plan identifier
+ explain\$1plan – explain plan text
+ plan\$1type:
+ `no plan` - no plan was captured
+ `estimate` - plan captured with estimated costs
+ `actual` - plan captured with EXPLAIN ANALYZE
+ plan\$1captured\$1time – last time a plan was captured
## Usage notes
`aurora_compute_plan_id` must be enabled and `pg_stat_statements` must be in `shared_preload_libraries` for the plans to be tracked.
The number of plans available is controlled by the value set in the `pg_stat_statements.max` parameter. When `aurora_compute_plan_id` is enabled, you can track the plans up to this specified value in `aurora_stat_plans`.
This function is available from Aurora PostgreSQL versions 14.10, 15.5, and for all other later versions.
## Examples
In the example below, the two plans that are for the query identifier -5471422286312252535 are captured and the statements statistics are tracked by the planid.
```
db1=# select calls, total_exec_time, planid, plan_captured_time, explain_plan
db1-# from aurora_stat_plans(true)
db1-# where queryid = '-5471422286312252535'
calls | total_exec_time | planid | plan_captured_time | explain_plan
---------+--------------------+-------------+-------------------------------+------------------------------------------------------------------
1532632 | 3209846.097107853 | 1602979607 | 2023-10-31 03:27:16.925497+00 | Update on pgbench_branches +
| | | | -> Bitmap Heap Scan on pgbench_branches +
| | | | Recheck Cond: (bid = 76) +
| | | | -> Bitmap Index Scan on pgbench_branches_pkey +
| | | | Index Cond: (bid = 76)
61365 | 124078.18012200127 | -2054628807 | 2023-10-31 03:20:09.85429+00 | Update on pgbench_branches +
| | | | -> Index Scan using pgbench_branches_pkey on pgbench_branches+
| | | | Index Cond: (bid = 17)
```
# aurora\$1stat\$1reset\$1wal\$1cache
Resets the counter for logical wal cache.
## Syntax
To reset a specific slot
```
SELECT * FROM aurora_stat_reset_wal_cache('slot_name')
```
To reset all slots
```
SELECT * FROM aurora_stat_reset_wal_cache(NULL)
```
## Arguments
`NULL` or `slot_name`
## Return type
Status message, text string
+ Reset the logical wal cache counter – Success message. This text is returned when the function succeeds.
+ Replication slot not found. Please try again. – Failure message. This text is returned when the function doesn't succeed.
## Usage notes
This function is available for the following versions.
+ Aurora PostgreSQL 14.5 and higher
+ Aurora PostgreSQL version 13.8 and higher
+ Aurora PostgreSQL version 12.12 and higher
+ Aurora PostgreSQLversion 11.17 and higher
## Examples
The following example uses the `aurora_stat_reset_wal_cache` function to reset a slot named `test_results`, and then tries to reset a slot that doesn't exist.
```
=> SELECT *
FROM aurora_stat_reset_wal_cache('test_slot');
aurora_stat_reset_wal_cache
--------------------------------------
Reset the logical wal cache counter.
(1 row)
=> SELECT *
FROM aurora_stat_reset_wal_cache('slot-not-exist');
aurora_stat_reset_wal_cache
-----------------------------------------------
Replication slot not found. Please try again.
(1 row)
```
# aurora\$1stat\$1resource\$1usage
Reports the real-time resource utilization which consists of backend resource metrics and cpu usage for all Aurora PostgreSQL backend processes.
## Syntax
```
aurora_stat_resource_usage()
```
## Arguments
None
## Return type
SETOF record with columns:
+ pid - Process identifier
+ allocated\$1memory - Total memory allocated by process in bytes
+ used\$1memory - Actually used memory by process in bytes
+ cpu\$1usage\$1percent - CPU usage percentage of the process
## Usage notes
This function displays the backend resource usage for each Aurora PostgreSQL backend process.
This function is available starting with the following Aurora PostgreSQL versions:
+ Aurora PostgreSQL 17.5 and higher 17 versions
+ Aurora PostgreSQL 16.9 and higher 16 versions
+ Aurora PostgreSQL 15.13 and higher 15 versions
+ Aurora PostgreSQL 14.18 and higher 14 versions
+ Aurora PostgreSQL 13.21 and higher 13 versions
## Examples
The following example shows the output of the `aurora_stat_resource_usage` function.
```
=> select * from aurora_stat_resource_usage();
pid | allocated_memory | used_memory | cpu_usage_percent
------+------------------+-------------+-----------------------
666 | 1074032 | 333544 | 0.00729274882897963
667 | 787312 | 287360 | 0.0029263928146372746
668 | 3076776 | 1563488 | 0.006013116835953961
684 | 803744 | 307480 | 0.002226855426881142
2401 | 1232992 | 943144 | 0
647 | 8000 | 944 | 0.48853387812429855
659 | 319344 | 243000 | 0.0004135602076683591
663 | 262000 | 185736 | 0.008181301476644002
664 | 9024 | 1216 | 0.10992313082653653
(9 rows)
```
# aurora\$1stat\$1statements
Displays all `pg_stat_statements` columns and adds more columns in the end.
## Syntax
```
aurora_stat_statements(showtext boolean)
```
## Arguments
*showtext boolean*
## Return type
SETOF record with all `pg_stat_statements` columns and the following additional columns. For more information on `pg_stat_statements` columns, see [https://www.postgresql.org/docs/current/pgstatstatements.html](https://www.postgresql.org/docs/current/pgstatstatements.html).
You can reset stats for this function using `pg_stat_statements_reset()`.
+ `storage_blks_read` – Total number of shared blocks read from aurora storage by this statement.
+ `orcache_blks_hit` – Total number of optimized reads cache hits by this statement.
+ `storage_blk_read_time` – If `track_io_timing` is enabled, it tracks the total time the statement spent reading shared blocks from aurora storage, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `local_blk_read_time` – If `track_io_timing` is enabled, it tracks the total time the statement spent reading local blocks, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `orcache_blk_read_time` – If `track_io_timing` is enabled, it tracks the total time the statement spent reading shared blocks from optimized reads cache, in milliseconds, otherwise the value is zero. For more information, see [track\$1io\$1timing](https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING).
+ `total_plan_peakmem` – Total sum of peak memory values during planning phase for all calls to this statement. To see the average peak memory during planning for the statement, divide this value by the number of calls.
+ `min_plan_peakmem` – Smallest peak memory value seen during planning across all calls to this statement.
+ `max_plan_peakmem` – Largest peak memory value during planning seen across all calls to this statement.
+ `total_exec_peakmem` – Total sum of peak memory values during execution phase for all calls to this statement. To see the average peak memory during execution for the statement, divide this value by the number of calls.
+ `min_exec_peakmem` –Smallest peak memory value, in bytes, seen during execution across all calls to this statement.
+ `max_exec_peakmem` – Largest peak memory value, in bytes, seen during execution across all calls to this statement.
**Note**
`total_plan_peakmen`, `min_plan_peakmem`, and `max_plan_peakmem` are only monitored when the setting `pg_stat_statements.track_planning` is turned on.
## Usage notes
To use the aurora\$1stat\$1statements() function, you must include `pg_stat_statements` extension in the `shared_preload_libraries` parameter.
This function is available in the following Aurora PostgreSQL versions:
+ 15.4 and higher 15 versions
+ 14.9 and higher 14 versions
The columns showing peak memory are available from the following versions:
+ 16.3 and higher versions
+ 15.7 and higher versions
+ 14.12 and higher versions
## Examples
The following example shows how it carries all the pg\$1stat\$1statements columns and append 11 new columns in the end:
```
=> select * from aurora_stat_statements(true) where query like 'with window_max%';
-[ RECORD 1 ]----------+------------------------------------------------------------------------------------------------
userid | 16409
dbid | 5
toplevel | t
queryid | -8347523682669847482
query | with window_max as (select custid, max(scratch) over (order by scratch rows between $1 preceding
and $2 following) wmax from ts) select sum(wmax), max(custid) from window_max
plans | 0
total_plan_time | 0
min_plan_time | 0
max_plan_time | 0
mean_plan_time | 0
stddev_plan_time | 0
calls | 4
total_exec_time | 254.105121
min_exec_time | 57.503164000000005
max_exec_time | 68.687418
mean_exec_time | 63.52628025
stddev_exec_time | 5.150765359979643
rows | 4
shared_blks_hit | 200192
shared_blks_read | 0
shared_blks_dirtied | 0
shared_blks_written | 0
local_blks_hit | 0
local_blks_read | 0
local_blks_dirtied | 0
local_blks_written | 0
temp_blks_read | 0
temp_blks_written | 0
blk_read_time | 0
blk_write_time | 0
temp_blk_read_time | 0
temp_blk_write_time | 0
wal_records | 0
wal_fpi | 0
wal_bytes | 0
jit_functions | 0
jit_generation_time | 0
jit_inlining_count | 0
jit_inlining_time | 0
jit_optimization_count | 0
jit_optimization_time | 0
jit_emission_count | 0
jit_emission_time | 0
storage_blks_read | 0
orcache_blks_hit | 0
storage_blk_read_time | 0
local_blk_read_time | 0
orcache_blk_read_time | 0
total_plan_peakmem | 0
min_plan_peakmem | 0
max_plan_peakmem | 0
total_exec_peakmem | 6356224
min_exec_peakmem | 1589056
max_exec_peakmem | 1589056
```
# aurora\$1stat\$1system\$1waits
Reports wait event information for the Aurora PostgreSQL DB instance.
## Syntax
```
aurora_stat_system_waits()
```
## Arguments
None
## Return type
SETOF record
## Usage notes
This function returns the cumulative number of waits and cumulative wait time for each wait event generated by the DB instance that you're currently connected to.
The returned recordset includes the following fields:
+ `type_id` – The ID of the type of wait event.
+ `event_id` – The ID of the wait event.
+ `waits` – The number of times the wait event occurred.
+ `wait_time` – The total amount of time in microseconds spent waiting for this event.
Statistics returned by this function are reset when a DB instance restarts.
## Examples
The following example shows results from calling the `aurora_stat_system_waits` function.
```
=> SELECT *
FROM aurora_stat_system_waits();
type_id | event_id | waits | wait_time
---------+-----------+-----------+--------------
1 | 16777219 | 11 | 12864
1 | 16777220 | 501 | 174473
1 | 16777270 | 53171 | 23641847
1 | 16777271 | 23 | 319668
1 | 16777274 | 60 | 12759
.
.
.
10 | 167772231 | 204596 | 790945212
10 | 167772232 | 2 | 47729
10 | 167772234 | 1 | 888
10 | 167772235 | 2 | 64
```
The following example shows how you can use this function together with `aurora_stat_wait_event` and `aurora_stat_wait_type` to produce more readable results.
```
=> SELECT type_name,
event_name,
waits,
wait_time
FROM aurora_stat_system_waits()
NATURAL JOIN aurora_stat_wait_event()
NATURAL JOIN aurora_stat_wait_type();
type_name | event_name | waits | wait_time
-----------+------------------------+----------+--------------
LWLock | XidGenLock | 11 | 12864
LWLock | ProcArrayLock | 501 | 174473
LWLock | buffer_content | 53171 | 23641847
LWLock | rdsutils | 2 | 12764
Lock | tuple | 75686 | 2033956052
Lock | transactionid | 1765147 | 47267583409
Activity | AutoVacuumMain | 136868 | 56305604538
Activity | BgWriterHibernate | 7486 | 55266949471
Activity | BgWriterMain | 7487 | 1508909964
.
.
.
IO | SLRURead | 3 | 11756
IO | WALWrite | 52544463 | 388850428
IO | XactSync | 187073 | 597041642
IO | ClogRead | 2 | 47729
IO | OutboundCtrlRead | 1 | 888
IO | OutboundCtrlWrite | 2 | 64
```
# aurora\$1stat\$1wait\$1event
Lists all supported wait events for Aurora PostgreSQL. For information about Aurora PostgreSQL wait events, see [Amazon Aurora PostgreSQL wait events](AuroraPostgreSQL.Reference.Waitevents.md).
## Syntax
```
aurora_stat_wait_event()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ type\$1id – The ID of the type of wait event.
+ event\$1id – The ID of the wait event.
+ type\$1name – Wait type name
+ event\$1name – Wait event name
## Usage notes
To see event names with event types instead of IDs, use this function together with other functions such as `aurora_stat_wait_type` and `aurora_stat_system_waits`. Wait event names returned by this function are the same as those returned by the `aurora_wait_report` function.
## Examples
The following example shows results from calling the `aurora_stat_wait_event` function.
```
=> SELECT *
FROM aurora_stat_wait_event();
type_id | event_id | event_name
---------+-----------+-------------------------------------------
1 | 16777216 |
1 | 16777217 | ShmemIndexLock
1 | 16777218 | OidGenLock
1 | 16777219 | XidGenLock
.
.
.
9 | 150994945 | PgSleep
9 | 150994946 | RecoveryApplyDelay
10 | 167772160 | BufFileRead
10 | 167772161 | BufFileWrite
10 | 167772162 | ControlFileRead
.
.
.
10 | 167772226 | WALInitWrite
10 | 167772227 | WALRead
10 | 167772228 | WALSync
10 | 167772229 | WALSyncMethodAssign
10 | 167772230 | WALWrite
10 | 167772231 | XactSync
.
.
.
11 | 184549377 | LsnAllocate
```
The following example joins `aurora_stat_wait_type` and `aurora_stat_wait_event` to return type names and event names for improved readability.
```
=> SELECT *
FROM aurora_stat_wait_type() t
JOIN aurora_stat_wait_event() e
ON t.type_id = e.type_id;
type_id | type_name | type_id | event_id | event_name
---------+-----------+---------+-----------+-------------------------------------------
1 | LWLock | 1 | 16777216 |
1 | LWLock | 1 | 16777217 | ShmemIndexLock
1 | LWLock | 1 | 16777218 | OidGenLock
1 | LWLock | 1 | 16777219 | XidGenLock
1 | LWLock | 1 | 16777220 | ProcArrayLock
.
.
.
3 | Lock | 3 | 50331648 | relation
3 | Lock | 3 | 50331649 | extend
3 | Lock | 3 | 50331650 | page
3 | Lock | 3 | 50331651 | tuple
.
.
.
10 | IO | 10 | 167772214 | TimelineHistorySync
10 | IO | 10 | 167772215 | TimelineHistoryWrite
10 | IO | 10 | 167772216 | TwophaseFileRead
10 | IO | 10 | 167772217 | TwophaseFileSync
.
.
.
11 | LSN | 11 | 184549376 | LsnDurable
```
# aurora\$1stat\$1wait\$1type
Lists all supported wait types for Aurora PostgreSQL.
## Syntax
```
aurora_stat_wait_type()
```
## Arguments
None
## Return type
SETOF record with the following columns:
+ type\$1id – The ID of the type of wait event.
+ type\$1name – Wait type name.
## Usage notes
To see wait event names with wait event types instead of IDs, use this function together with other functions such as `aurora_stat_wait_event` and `aurora_stat_system_waits`. Wait type names returned by this function are the same as those returned by the `aurora_wait_report` function.
## Examples
The following example shows results from calling the `aurora_stat_wait_type` function.
```
=> SELECT *
FROM aurora_stat_wait_type();
type_id | type_name
---------+-----------
1 | LWLock
3 | Lock
4 | BufferPin
5 | Activity
6 | Client
7 | Extension
8 | IPC
9 | Timeout
10 | IO
11 | LSN
```
# aurora\$1version
Returns the string value of the Amazon Aurora PostgreSQL-Compatible Edition version number.
## Syntax
```
aurora_version()
```
## Arguments
None
## Return type
CHAR or VARCHAR string
## Usage notes
This function displays the version of the Amazon Aurora PostgreSQL-Compatible Edition database engine. The version number is returned as a string formatted as *major*.*minor*.*patch*. For more information about Aurora PostgreSQL version numbers, see [Aurora version number](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions.AuroraNumber).
You can choose when to apply minor version upgrades by setting the maintenance window for your Aurora PostgreSQL DB cluster. To learn how, see [Maintaining an Amazon Aurora DB cluster](USER_UpgradeDBInstance.Maintenance.md).
Starting with the release of Aurora PostgreSQL versions 13.3, 12.8, 11.13, 10.18, and for all other later versions, Aurora version numbers follow PostgreSQL version numbers. For more information about all Aurora PostgreSQL releases, see [Amazon Aurora PostgreSQL updates](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html) in the *Release Notes for Aurora PostgreSQL*.
## Examples
The following example shows the results of calling the `aurora_version` function on an Aurora PostgreSQL DB cluster running [PostgreSQL 12.7, Aurora PostgreSQL release 4.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.42) and then running the same function on a cluster running [Aurora PostgreSQL version 13.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.133X).
```
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
```
This example shows how to use the function with various options to get more detail about the Aurora PostgreSQL version. This example has an Aurora version number that's distinct from the PostgreSQL version number.
```
=> SHOW SERVER_VERSION;
server_version
----------------
12.7
(1 row)
=> SELECT * FROM aurora_version();
aurora_version
----------------
4.2.2
(1 row)
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
12.7
(1 row)
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------------------
PostgreSQL 12.7 on aarch64-unknown-linux-gnu, compiled by aarch64-unknown-linux-gnu-gcc (GCC) 7.4.0, 64-bit
(1 row)
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
------------------------------------------------
Aurora: 4.2.2 Compatible with PostgreSQL: 12.7
(1 row)
```
This next example uses the function with the same options in the previous example. This example doesn't have an Aurora version number that's distinct from the PostgreSQL version number.
```
=> SHOW SERVER_VERSION;
server_version
----------------
13.3
=> SELECT * FROM aurora_version();
aurora_version
----------------
13.3.0
=> SELECT current_setting('server_version') AS "PostgreSQL Compatiblility";
PostgreSQL Compatiblility
---------------------------
13.3
=> SELECT version() AS "PostgreSQL Compatiblility Full String";
PostgreSQL Compatiblility Full String
-------------------------------------------------------------------------------------------------
PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 7.4.0, 64-bit
=> SELECT 'Aurora: '
|| aurora_version()
|| ' Compatible with PostgreSQL: '
|| current_setting('server_version') AS "Instance Version";
Instance Version
-------------------------------------------------------
Aurora: 13.3.0 Compatible with PostgreSQL: 13.3
```
# aurora\$1volume\$1logical\$1start\$1lsn
Returns the log sequence number (LSN) used for identifying the beginning of a record in the logical write-ahead log (WAL) stream of the Aurora cluster volume.
## Syntax
```
aurora_volume_logical_start_lsn()
```
## Arguments
None
## Return type
`pg_lsn`
## Usage notes
This function identifies the beginning of the record in the logical WAL stream for a given Aurora cluster volume. You can use this function while performing major version upgrade using logical replication and Aurora fast cloning to determine the LSN at which a snapshot or database clone is taken. You can then use logical replication to continuously stream the newer data recorded after the LSN and synchronize the changes from publisher to subscriber.
For more information on using logical replication for a major version upgrade, see [Using logical replication to perform a major version upgrade for Aurora PostgreSQL](AuroraPostgreSQL.MajorVersionUpgrade.md).
This function is available on the following versions of Aurora PostgreSQL:
+ 15.2 and higher 15 versions
+ 14.3 and higher 14 versions
+ 13.6 and higher 13 versions
+ 12.10 and higher 12 versions
+ 11.15 and higher 11 versions
+ 10.20 and higher 10 versions
## Examples
You can obtain the log sequence number (LSN) using the following query:
```
postgres=> SELECT aurora_volume_logical_start_lsn();
aurora_volume_logical_start_lsn
---------------
0/402E2F0
(1 row)
```
# aurora\$1wait\$1report
This function shows wait event activity over a period of time.
## Syntax
```
aurora_wait_report([time])
```
## Arguments
*time (optional) *
The time in seconds. Default is 10 seconds.
## Return type
SETOF record with the following columns:
+ type\$1name – Wait type name
+ event\$1name – Wait event name
+ wait – Number of waits
+ wait\$1time – Wait time in milliseconds
+ ms\$1per\$1wait – Average milliseconds by the number of an wait
+ waits\$1per\$1xact – Average waits by the number of one transaction
+ ms\$1per\$1xact – Average milliseconds by the number of transactions
## Usage notes
This function is available as of Aurora PostgreSQL release 1.1 compatible with PostgreSQL 9.6.6 and higher versions.
To use this function, you need to first create the Aurora PostgreSQL `aurora_stat_utils` extension, as follows:
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
For more information about available Aurora PostgreSQL extension versions, see [Extension versions for Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in *Release Notes for Aurora PostgreSQL*.
This function calculates the instance-level wait events by comparing two snapshots of statistics data from aurora\$1stat\$1system\$1waits() function and pg\$1stat\$1database PostgreSQL Statistics Views.
For more information about `aurora_stat_system_waits()` and `pg_stat_database`, see [The Statistics Collector](https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-DATABASE-VIEW) in the *PostgreSQL documentation*.
When run, this function takes an initial snapshot, waits the number of seconds specified, and then takes a second snapshot. The function compares the two snapshots and returns the difference. This difference represents the instance's activity for that time interval.
On the writer instance, the function also displays the number of committed transactions and TPS (transactions per second). This function returns information at the instance level and includes all databases on the instance.
## Examples
This example shows how to create aurora\$1stat\$1utils extension to be able to use aurora\$1wait\$1report function.
```
=> CREATE extension aurora_stat_utils;
CREATE EXTENSION
```
This example shows how to check wait report for 10 seconds.
```
=> SELECT *
FROM aurora_wait_report();
NOTICE: committed 34 transactions in 10 seconds (tps 3)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+-------------------+-------+-----------+-------------+----------------+-------------
Client | ClientRead | 26 | 30003.00 | 1153.961 | 0.76 | 882.441
Activity | WalWriterMain | 50 | 10051.32 | 201.026 | 1.47 | 295.627
Timeout | PgSleep | 1 | 10049.52 | 10049.516 | 0.03 | 295.574
Activity | BgWriterHibernate | 1 | 10048.15 | 10048.153 | 0.03 | 295.534
Activity | AutoVacuumMain | 18 | 9941.66 | 552.314 | 0.53 | 292.402
Activity | BgWriterMain | 1 | 201.09 | 201.085 | 0.03 | 5.914
IO | XactSync | 15 | 25.34 | 1.690 | 0.44 | 0.745
IO | RelationMapRead | 12 | 0.54 | 0.045 | 0.35 | 0.016
IO | WALWrite | 84 | 0.21 | 0.002 | 2.47 | 0.006
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.03 | 0.001
```
This example shows how to check wait report for 60 seconds.
```
=> SELECT *
FROM aurora_wait_report(60);
NOTICE: committed 1544 transactions in 60 seconds (tps 25)
type_name | event_name | waits | wait_time | ms_per_wait | waits_per_xact | ms_per_xact
-----------+------------------------+---------+-----------+-------------+----------------+-------------
Lock | transactionid | 6422 | 477000.53 | 74.276 | 4.16 | 308.938
Client | ClientRead | 8265 | 270752.99 | 32.759 | 5.35 | 175.358
Activity | CheckpointerMain | 1 | 60100.25 | 60100.246 | 0.00 | 38.925
Timeout | PgSleep | 1 | 60098.49 | 60098.493 | 0.00 | 38.924
Activity | WalWriterMain | 296 | 60010.99 | 202.740 | 0.19 | 38.867
Activity | AutoVacuumMain | 107 | 59827.84 | 559.139 | 0.07 | 38.749
Activity | BgWriterMain | 290 | 58821.83 | 202.834 | 0.19 | 38.097
IO | XactSync | 1295 | 55220.13 | 42.641 | 0.84 | 35.764
IO | WALWrite | 6602259 | 47810.94 | 0.007 | 4276.07 | 30.966
Lock | tuple | 473 | 29880.67 | 63.173 | 0.31 | 19.353
LWLock | buffer_mapping | 142 | 3540.13 | 24.930 | 0.09 | 2.293
Activity | BgWriterHibernate | 290 | 1124.15 | 3.876 | 0.19 | 0.728
IO | BufFileRead | 7615 | 618.45 | 0.081 | 4.93 | 0.401
LWLock | buffer_content | 73 | 345.93 | 4.739 | 0.05 | 0.224
LWLock | lock_manager | 62 | 191.44 | 3.088 | 0.04 | 0.124
IO | RelationMapRead | 72 | 5.16 | 0.072 | 0.05 | 0.003
LWLock | ProcArrayLock | 1 | 2.01 | 2.008 | 0.00 | 0.001
IO | ControlFileWriteUpdate | 2 | 0.03 | 0.013 | 0.00 | 0.000
IO | DataFileExtend | 1 | 0.02 | 0.018 | 0.00 | 0.000
IO | ControlFileSyncUpdate | 1 | 0.00 | 0.000 | 0.00 | 0.000
```
# Amazon Aurora PostgreSQL parameters
You manage your Amazon Aurora DB cluster in the same way that you manage Amazon RDS DB instances, by using parameters in a DB parameter group. However, Amazon Aurora differs from Amazon RDS in that an Aurora DB cluster has multiple DB instances. Some of the parameters that you use to manage your Amazon Aurora DB cluster apply to the entire cluster, while other parameters apply only to a given DB instance in the DB cluster, as follows:
+ **DB cluster parameter group** – A DB cluster parameter group contains the set of engine configuration parameters that apply throughout the Aurora DB cluster. For example, cluster cache management is a feature of an Aurora DB cluster that's controlled by the `apg_ccm_enabled` parameter which is part of the DB cluster parameter group. The DB cluster parameter group also contains default settings for the DB parameter group for the DB instances that make up the cluster.
+ **DB parameter group** – A DB parameter group is the set of engine configuration values that apply to a specific DB instance of that engine type. The DB parameter groups for the PostgreSQL DB engine are used by an RDS for PostgreSQL DB instance and Aurora PostgreSQL DB cluster. These configuration settings apply to properties that can vary among the DB instances within an Aurora cluster, such as the sizes for memory buffers.
You manage cluster-level parameters in DB cluster parameter groups. You manage instance-level parameters in DB parameter groups. You can manage parameters using the Amazon RDS console, the AWS CLI, or the Amazon RDS API. There are separate commands for managing cluster-level parameters and instance-level parameters.
+ To manage cluster-level parameters in a DB cluster parameter group, use the [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) AWS CLI command.
+ To manage instance-level parameters in a DB parameter group for a DB instance in a DB cluster, use the [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI command.
To learn more about the AWS CLI, see [Using the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-using.html) in the *AWS Command Line Interface User Guide*.
For more information about parameter groups, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).
## Viewing Aurora PostgreSQL DB cluster and DB parameters
You can view all available default parameter groups for RDS for PostgreSQL DB instances and for Aurora PostgreSQL DB clusters in the AWS Management Console. The default parameter groups for all DB engines and DB cluster types and versions are listed for each AWS Region. Any custom parameter groups are also listed.
Rather than viewing in the AWS Management Console, you can also list parameters contained in DB cluster parameter groups and DB parameter groups by using the AWS CLI or the Amazon RDS API. For example, to list parameters in a DB cluster parameter group you use the [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) AWS CLI command as follows:
```
aws rds describe-db-cluster-parameters --db-cluster-parameter-group-name default.aurora-postgresql12
```
The command returns detailed JSON descriptions of each parameter. To reduce the amount of information returned, you can specify what you want by using the `--query` option. For example, you can get the parameter name, its description, and allowed values for the default Aurora PostgreSQL 12 DB cluster parameter group as follows:
For Linux, macOS, or Unix:
```
aws rds describe-db-cluster-parameters --db-cluster-parameter-group-name default.aurora-postgresql12 \
--query 'Parameters[].[{ParameterName:ParameterName,Description:Description,ApplyType:ApplyType,AllowedValues:AllowedValues}]'
```
For Windows:
```
aws rds describe-db-cluster-parameters --db-cluster-parameter-group-name default.aurora-postgresql12 ^
--query "Parameters[].[{ParameterName:ParameterName,Description:Description,ApplyType:ApplyType,AllowedValues:AllowedValues}]"
```
An Aurora DB cluster parameter group includes the DB instance parameter group and default values for a given Aurora DB engine. You can get the list of DB parameters from the same default Aurora PostgreSQL default parameter group by usng the [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI command as shown following.
For Linux, macOS, or Unix:
```
aws rds describe-db-parameters --db-parameter-group-name default.aurora-postgresql12 \
--query 'Parameters[].[{ParameterName:ParameterName,Description:Description,ApplyType:ApplyType,AllowedValues:AllowedValues}]'
```
For Windows:
```
aws rds describe-db-parameters --db-parameter-group-name default.aurora-postgresql12 ^
--query "Parameters[].[{ParameterName:ParameterName,Description:Description,ApplyType:ApplyType,AllowedValues:AllowedValues}]"
```
The preceding commands return lists of parameters from the DB cluster or DB parameter group with descriptions and other details specified in the query. Following is an example response.
```
[
[
{
"ParameterName": "apg_enable_batch_mode_function_execution",
"ApplyType": "dynamic",
"Description": "Enables batch-mode functions to process sets of rows at a time.",
"AllowedValues": "0,1"
}
],
[
{
"ParameterName": "apg_enable_correlated_any_transform",
"ApplyType": "dynamic",
"Description": "Enables the planner to transform correlated ANY Sublink (IN/NOT IN subquery) to JOIN when possible.",
"AllowedValues": "0,1"
}
],...
```
Following are tables containing values for the default DB cluster parameter and DB parameter for Aurora PostgreSQL version 14.
## Aurora PostgreSQL cluster-level parameters
You can view the cluster-level parameters available for a specific Aurora PostgreSQL version using the AWS Management console, the AWS CLI, or the Amazon RDS API. For information about viewing the parameters in an Aurora PostgreSQL DB cluster parameter groups in the RDS console, see [Viewing parameter values for a DB cluster parameter groupin Amazon Aurora](USER_WorkingWithParamGroups.ViewingCluster.md).
Some cluster-level parameters aren't available in all versions and some are being deprecated. For information about viewing the parameters of a specific Aurora PostgreSQL version, see [Viewing Aurora PostgreSQL DB cluster and DB parameters](#AuroraPostgreSQL.Reference.ParameterGroups-viewing-parameters).
For example, the following table lists the parameters available in the default DB cluster parameter group for Aurora PostgreSQL version 14. If you create an Aurora PostgreSQL DB cluster without specifying your own custom DB parameter group, your DB cluster is created using the default Aurora DB cluster parameter group for the version chosen, such as `default.aurora-postgresql14`, `default.aurora-postgresql13`, and so on.
For a listing of the DB instance parameters for this same default DB cluster parameter group, see [Aurora PostgreSQL instance-level parameters](#AuroraPostgreSQL.Reference.Parameters.Instance).
| Parameter name | Description | Default |
| --- | --- | --- |
| ansi\$1constraint\$1trigger\$1ordering | Change the firing order of constraint triggers to be compatible with the ANSI SQL standard. | – |
| ansi\$1force\$1foreign\$1key\$1checks | Ensure referential actions such as cascaded delete or cascaded update will always occur regardless of the various trigger contexts that exist for the action. | – |
| ansi\$1qualified\$1update\$1set\$1target | Support table and schema qualifiers in UPDATE ... SET statements. | – |
| apg\$1ccm\$1enabled | Enable or disable cluster cache management for the cluster. | – |
| apg\$1enable\$1batch\$1mode\$1function\$1execution | Enables batch-mode functions to process sets of rows at a time. | – |
| apg\$1enable\$1correlated\$1any\$1transform | Enables the planner to transform correlated ANY Sublink (IN/NOT IN subquery) to JOIN when possible. | – |
| apg\$1enable\$1function\$1migration | Enables the planner to migrate eligible scalar functions to the FROM clause. | – |
| apg\$1enable\$1not\$1in\$1transform | Enables the planner to transform NOT IN subquery to ANTI JOIN when possible. | – |
| apg\$1enable\$1remove\$1redundant\$1inner\$1joins | Enables the planner to remove redundant inner joins. | – |
| apg\$1enable\$1semijoin\$1push\$1down | Enables the use of semijoin filters for hash joins. | – |
| apg\$1plan\$1mgmt.capture\$1plan\$1baselines | Capture plan baseline mode. manual - enable plan capture for any SQL statement, off - disable plan capture, automatic - enable plan capture for for statements in pg\$1stat\$1statements that satisfy the eligibility criteria. | off |
| apg\$1plan\$1mgmt.max\$1databases | Sets the maximum number of databases that that may manage queries using apg\$1plan\$1mgmt. | 10 |
| apg\$1plan\$1mgmt.max\$1plans | Sets the maximum number of plans that may be cached by apg\$1plan\$1mgmt. | 10000 |
| apg\$1plan\$1mgmt.plan\$1retention\$1period | Maximum number of days since a plan was last\$1used before a plan will be automatically deleted. | 32 |
| apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold | Estimated total plan cost below which an Unapproved plan will be executed. | 0 |
| apg\$1plan\$1mgmt.use\$1plan\$1baselines | Use only approved or fixed plans for managed statements. | false |
| application\$1name | Sets the application name to be reported in statistics and logs. | – |
| array\$1nulls | Enable input of NULL elements in arrays. | – |
| aurora\$1compute\$1plan\$1id | Monitors query execution plans to detect the execution plans contributing to current database load and to track performance statistics of execution plans over time. For more information, see [Monitoring query execution plans for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html). | on |
| authentication\$1timeout | (s) Sets the maximum allowed time to complete client authentication. | – |
| auto\$1explain.log\$1analyze | Use EXPLAIN ANALYZE for plan logging. | – |
| auto\$1explain.log\$1buffers | Log buffers usage. | – |
| auto\$1explain.log\$1format | EXPLAIN format to be used for plan logging. | – |
| auto\$1explain.log\$1min\$1duration | Sets the minimum execution time above which plans will be logged. | – |
| auto\$1explain.log\$1nested\$1statements | Log nested statements. | – |
| auto\$1explain.log\$1timing | Collect timing data, not just row counts. | – |
| auto\$1explain.log\$1triggers | Include trigger statistics in plans. | – |
| auto\$1explain.log\$1verbose | Use EXPLAIN VERBOSE for plan logging. | – |
| auto\$1explain.sample\$1rate | Fraction of queries to process. | – |
| autovacuum | Starts the autovacuum subprocess. | – |
| autovacuum\$1analyze\$1scale\$1factor | Number of tuple inserts, updates or deletes prior to analyze as a fraction of reltuples. | 0.05 |
| autovacuum\$1analyze\$1threshold | Minimum number of tuple inserts, updates or deletes prior to analyze. | – |
| autovacuum\$1freeze\$1max\$1age | Age at which to autovacuum a table to prevent transaction ID wraparound. | – |
| autovacuum\$1max\$1workers | Sets the maximum number of simultaneously running autovacuum worker processes. | GREATEST(DBInstanceClassMemory/64371566592,3) |
| autovacuum\$1multixact\$1freeze\$1max\$1age | Multixact age at which to autovacuum a table to prevent multixact wraparound. | – |
| autovacuum\$1naptime | (s) Time to sleep between autovacuum runs. | 5 |
| autovacuum\$1vacuum\$1cost\$1delay | (ms) Vacuum cost delay in milliseconds, for autovacuum. | 5 |
| autovacuum\$1vacuum\$1cost\$1limit | Vacuum cost amount available before napping, for autovacuum. | GREATEST(log(DBInstanceClassMemory/21474836480)\$1600,200) |
| autovacuum\$1vacuum\$1insert\$1scale\$1factor | Number of tuple inserts prior to vacuum as a fraction of reltuples. | – |
| autovacuum\$1vacuum\$1insert\$1threshold | Minimum number of tuple inserts prior to vacuum, or -1 to disable insert vacuums. | – |
| autovacuum\$1vacuum\$1scale\$1factor | Number of tuple updates or deletes prior to vacuum as a fraction of reltuples. | 0.1 |
| autovacuum\$1vacuum\$1threshold | Minimum number of tuple updates or deletes prior to vacuum. | – |
| autovacuum\$1work\$1mem | (kB) Sets the maximum memory to be used by each autovacuum worker process. | GREATEST(DBInstanceClassMemory/32768,131072) |
| babelfishpg\$1tds.default\$1server\$1name | Default Babelfish server name | Microsoft SQL Server |
| babelfishpg\$1tds.listen\$1addresses | Sets the host name or IP address(es) to listen TDS to. | \$1 |
| babelfishpg\$1tds.port | Sets the TDS TCP port the server listens on. | 1433 |
| babelfishpg\$1tds.tds\$1debug\$1log\$1level | Sets logging level in TDS, 0 disables logging | 1 |
| babelfishpg\$1tds.tds\$1default\$1numeric\$1precision | Sets the default precision of numeric type to be sent in the TDS column metadata if the engine does not specify one. | 38 |
| babelfishpg\$1tds.tds\$1default\$1numeric\$1scale | Sets the default scale of numeric type to be sent in the TDS column metadata if the engine does not specify one. | 8 |
| babelfishpg\$1tds.tds\$1default\$1packet\$1size | Sets the default packet size for all the SQL Server clients being connected | 4096 |
| babelfishpg\$1tds.tds\$1default\$1protocol\$1version | Sets a default TDS protocol version for all the clients being connected | DEFAULT |
| babelfishpg\$1tds.tds\$1ssl\$1encrypt | Sets the SSL Encryption option | 0 |
| babelfishpg\$1tds.tds\$1ssl\$1max\$1protocol\$1version | Sets the maximum SSL/TLS protocol version to use for tds session. | TLSv1.2 |
| babelfishpg\$1tds.tds\$1ssl\$1min\$1protocol\$1version | Sets the minimum SSL/TLS protocol version to use for tds session. | TLSv1.2 from Aurora PostgreSQL version 16, TLSv1 for versions older than Aurora PostgreSQL version 16 |
| babelfishpg\$1tsql.default\$1locale | Default locale to be used for collations created by CREATE COLLATION. | en-US |
| babelfishpg\$1tsql.migration\$1mode | Defines if multiple user databases are supported | multi-db from Aurora PostgreSQL version 16, single-db for versions older than Aurora PostgreSQL version 16 |
| babelfishpg\$1tsql.server\$1collation\$1name | Name of the default server collation | sql\$1latin1\$1general\$1cp1\$1ci\$1as |
| babelfishpg\$1tsql.version | Sets the output of @@VERSION variable | default |
| backend\$1flush\$1after | (8Kb) Number of pages after which previously performed writes are flushed to disk. | – |
| backslash\$1quote | Sets whether \$1\$1 is allowed in string literals. | – |
| backtrace\$1functions | Log backtrace for errors in these functions. | – |
| bytea\$1output | Sets the output format for bytea. | – |
| check\$1function\$1bodies | Check function bodies during CREATE FUNCTION. | – |
| client\$1connection\$1check\$1interval | Sets the time interval between checks for disconnection while running queries. | – |
| client\$1encoding | Sets the clients character set encoding. | UTF8 |
| client\$1min\$1messages | Sets the message levels that are sent to the client. | – |
| compute\$1query\$1id | Compute query identifiers. | auto |
| config\$1file | Sets the servers main configuration file. | /rdsdbdata/config/postgresql.conf |
| constraint\$1exclusion | Enables the planner to use constraints to optimize queries. | – |
| cpu\$1index\$1tuple\$1cost | Sets the planners estimate of the cost of processing each index entry during an index scan. | – |
| cpu\$1operator\$1cost | Sets the planners estimate of the cost of processing each operator or function call. | – |
| cpu\$1tuple\$1cost | Sets the planners estimate of the cost of processing each tuple (row). | – |
| cron.database\$1name | Sets the database to store pg\$1cron metadata tables | postgres |
| cron.log\$1run | Log all jobs runs into the job\$1run\$1details table | on |
| cron.log\$1statement | Log all cron statements prior to execution. | off |
| cron.max\$1running\$1jobs | Maximum number of jobs that can run concurrently. | 5 |
| cron.use\$1background\$1workers | Enables background workers for pg\$1cron | on |
| cursor\$1tuple\$1fraction | Sets the planners estimate of the fraction of a cursors rows that will be retrieved. | – |
| data\$1directory | Sets the servers data directory. | /rdsdbdata/db |
| datestyle | Sets the display format for date and time values. | – |
| db\$1user\$1namespace | Enables per-database user names. | – |
| deadlock\$1timeout | (ms) Sets the time to wait on a lock before checking for deadlock. | – |
| debug\$1pretty\$1print | Indents parse and plan tree displays. | – |
| debug\$1print\$1parse | Logs each querys parse tree. | – |
| debug\$1print\$1plan | Logs each querys execution plan. | – |
| debug\$1print\$1rewritten | Logs each querys rewritten parse tree. | – |
| default\$1statistics\$1target | Sets the default statistics target. | – |
| default\$1tablespace | Sets the default tablespace to create tables and indexes in. | – |
| default\$1toast\$1compression | Sets the default compression method for compressible values. | – |
| default\$1transaction\$1deferrable | Sets the default deferrable status of new transactions. | – |
| default\$1transaction\$1isolation | Sets the transaction isolation level of each new transaction. | – |
| default\$1transaction\$1read\$1only | Sets the default read-only status of new transactions. | – |
| effective\$1cache\$1size | (8kB) Sets the planners assumption about the size of the disk cache. | SUM(DBInstanceClassMemory/12038,-50003) |
| effective\$1io\$1concurrency | Number of simultaneous requests that can be handled efficiently by the disk subsystem. | – |
| enable\$1async\$1append | Enables the planners use of async append plans. | – |
| enable\$1bitmapscan | Enables the planners use of bitmap-scan plans. | – |
| enable\$1gathermerge | Enables the planners use of gather merge plans. | – |
| enable\$1hashagg | Enables the planners use of hashed aggregation plans. | – |
| enable\$1hashjoin | Enables the planners use of hash join plans. | – |
| enable\$1incremental\$1sort | Enables the planners use of incremental sort steps. | – |
| enable\$1indexonlyscan | Enables the planners use of index-only-scan plans. | – |
| enable\$1indexscan | Enables the planners use of index-scan plans. | – |
| enable\$1material | Enables the planners use of materialization. | – |
| enable\$1memoize | Enables the planners use of memoization | – |
| enable\$1mergejoin | Enables the planners use of merge join plans. | – |
| enable\$1nestloop | Enables the planners use of nested-loop join plans. | – |
| enable\$1parallel\$1append | Enables the planners use of parallel append plans. | – |
| enable\$1parallel\$1hash | Enables the planners user of parallel hash plans. | – |
| enable\$1partition\$1pruning | Enable plan-time and run-time partition pruning. | – |
| enable\$1partitionwise\$1aggregate | Enables partitionwise aggregation and grouping. | – |
| enable\$1partitionwise\$1join | Enables partitionwise join. | – |
| enable\$1seqscan | Enables the planners use of sequential-scan plans. | – |
| enable\$1sort | Enables the planners use of explicit sort steps. | – |
| enable\$1tidscan | Enables the planners use of TID scan plans. | – |
| escape\$1string\$1warning | Warn about backslash escapes in ordinary string literals. | – |
| exit\$1on\$1error | Terminate session on any error. | – |
| extra\$1float\$1digits | Sets the number of digits displayed for floating-point values. | – |
| force\$1parallel\$1mode | Forces use of parallel query facilities. | – |
| from\$1collapse\$1limit | Sets the FROM-list size beyond which subqueries are not collapsed. | – |
| geqo | Enables genetic query optimization. | – |
| geqo\$1effort | GEQO: effort is used to set the default for other GEQO parameters. | – |
| geqo\$1generations | GEQO: number of iterations of the algorithm. | – |
| geqo\$1pool\$1size | GEQO: number of individuals in the population. | – |
| geqo\$1seed | GEQO: seed for random path selection. | – |
| geqo\$1selection\$1bias | GEQO: selective pressure within the population. | – |
| geqo\$1threshold | Sets the threshold of FROM items beyond which GEQO is used. | – |
| gin\$1fuzzy\$1search\$1limit | Sets the maximum allowed result for exact search by GIN. | – |
| gin\$1pending\$1list\$1limit | (kB) Sets the maximum size of the pending list for GIN index. | – |
| hash\$1mem\$1multiplier | Multiple of work\$1mem to use for hash tables. | – |
| hba\$1file | Sets the servers hba configuration file. | /rdsdbdata/config/pg\$1hba.conf |
| hot\$1standby\$1feedback | Allows feedback from a hot standby to the primary that will avoid query conflicts. | on |
| huge\$1pages | Reduces overhead when a DB instance is working with large contiguous chunks of memory, such as that used by shared buffers. It is turned on by default for all the DB instance classes other than t3.medium,db.t3.large,db.t4g.medium,db.t4g.large instance classes. | on |
| ident\$1file | Sets the servers ident configuration file. | /rdsdbdata/config/pg\$1ident.conf |
| idle\$1in\$1transaction\$1session\$1timeout | (ms) Sets the maximum allowed duration of any idling transaction. | 86400000 |
| idle\$1session\$1timeout | Terminate any session that has been idle (that is, waiting for a client query), but not within an open transaction, for longer than the specified amount of time | – |
| intervalstyle | Sets the display format for interval values. | – |
| join\$1collapse\$1limit | Sets the FROM-list size beyond which JOIN constructs are not flattened. | – |
| krb\$1caseins\$1users | Sets whether GSSAPI (Generic Security Service API) user names should be treated case-insensitively (true) or not. By default, this parameter is set to false, so Kerberos expects user names to be case sensitive. For more information, see [GSSAPI Authentication](https://www.postgresql.org/docs/current/gssapi-auth.html) in the PostgreSQL documentation. | false |
| lc\$1messages | Sets the language in which messages are displayed. | – |
| lc\$1monetary | Sets the locale for formatting monetary amounts. | – |
| lc\$1numeric | Sets the locale for formatting numbers. | – |
| lc\$1time | Sets the locale for formatting date and time values. | – |
| listen\$1addresses | Sets the host name or IP address(es) to listen to. | \$1 |
| lo\$1compat\$1privileges | Enables backward compatibility mode for privilege checks on large objects. | 0 |
| log\$1autovacuum\$1min\$1duration | (ms) Sets the minimum execution time above which autovacuum actions will be logged. | 10000 |
| log\$1connections | Logs each successful connection. | – |
| log\$1destination | Sets the destination for server log output. | stderr |
| log\$1directory | Sets the destination directory for log files. | /rdsdbdata/log/error |
| log\$1disconnections | Logs end of a session, including duration. | – |
| log\$1duration | Logs the duration of each completed SQL statement. | – |
| log\$1error\$1verbosity | Sets the verbosity of logged messages. | – |
| log\$1executor\$1stats | Writes executor performance statistics to the server log. | – |
| log\$1file\$1mode | Sets the file permissions for log files. | 0644 |
| log\$1filename | Sets the file name pattern for log files. | postgresql.log.%Y-%m-%d-%H%M |
| logging\$1collector | Start a subprocess to capture stderr output and/or csvlogs into log files. | 1 |
| log\$1hostname | Logs the host name in the connection logs. | 0 |
| logical\$1decoding\$1work\$1mem | (kB) This much memory can be used by each internal reorder buffer before spilling to disk. | – |
| log\$1line\$1prefix | Controls information prefixed to each log line. | %t:%r:%u@%d:%p]: |
| log\$1lock\$1waits | Logs long lock waits. | – |
| log\$1min\$1duration\$1sample | (ms) Sets the minimum execution time above which a sample of statements will be logged. Sampling is determined by log\$1statement\$1sample\$1rate. | – |
| log\$1min\$1duration\$1statement | (ms) Sets the minimum execution time above which statements will be logged. | – |
| log\$1min\$1error\$1statement | Causes all statements generating error at or above this level to be logged. | – |
| log\$1min\$1messages | Sets the message levels that are logged. | – |
| log\$1parameter\$1max\$1length | (B) When logging statements, limit logged parameter values to first N bytes. | – |
| log\$1parameter\$1max\$1length\$1on\$1error | (B) When reporting an error, limit logged parameter values to first N bytes. | – |
| log\$1parser\$1stats | Writes parser performance statistics to the server log. | – |
| log\$1planner\$1stats | Writes planner performance statistics to the server log. | – |
| log\$1replication\$1commands | Logs each replication command. | – |
| log\$1rotation\$1age | (min) Automatic log file rotation will occur after N minutes. | 60 |
| log\$1rotation\$1size | (kB) Automatic log file rotation will occur after N kilobytes. | 100000 |
| log\$1statement | Sets the type of statements logged. | – |
| log\$1statement\$1sample\$1rate | Fraction of statements exceeding log\$1min\$1duration\$1sample to be logged. | – |
| log\$1statement\$1stats | Writes cumulative performance statistics to the server log. | – |
| log\$1temp\$1files | (kB) Log the use of temporary files larger than this number of kilobytes. | – |
| log\$1timezone | Sets the time zone to use in log messages. | UTC |
| log\$1transaction\$1sample\$1rate | Set the fraction of transactions to log for new transactions. | – |
| log\$1truncate\$1on\$1rotation | Truncate existing log files of same name during log rotation. | 0 |
| maintenance\$1io\$1concurrency | A variant of effective\$1io\$1concurrency that is used for maintenance work. | 1 |
| maintenance\$1work\$1mem | (kB) Sets the maximum memory to be used for maintenance operations. | GREATEST(DBInstanceClassMemory/63963136\$11024,65536) |
| max\$1connections | Sets the maximum number of concurrent connections. | LEAST(DBInstanceClassMemory/9531392,5000) |
| max\$1files\$1per\$1process | Sets the maximum number of simultaneously open files for each server process. | – |
| max\$1locks\$1per\$1transaction | Sets the maximum number of locks per transaction. | 64 |
| max\$1logical\$1replication\$1workers | Maximum number of logical replication worker processes. | – |
| max\$1parallel\$1maintenance\$1workers | Sets the maximum number of parallel processes per maintenance operation. | – |
| max\$1parallel\$1workers | Sets the maximum number of parallel workers than can be active at one time. | GREATEST(\$1DBInstanceVCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Sets the maximum number of parallel processes per executor node. | – |
| max\$1pred\$1locks\$1per\$1page | Sets the maximum number of predicate-locked tuples per page. | – |
| max\$1pred\$1locks\$1per\$1relation | Sets the maximum number of predicate-locked pages and tuples per relation. | – |
| max\$1pred\$1locks\$1per\$1transaction | Sets the maximum number of predicate locks per transaction. | – |
| max\$1prepared\$1transactions | Sets the maximum number of simultaneously prepared transactions. | 0 |
| max\$1replication\$1slots | Sets the maximum number of replication slots that the server can support. | 20 |
| max\$1slot\$1wal\$1keep\$1size | (MB) Replication slots will be marked as failed, and segments released for deletion or recycling, if this much space is occupied by WAL on disk. | – |
| max\$1stack\$1depth | (kB) Sets the maximum stack depth, in kilobytes. | 6144 |
| max\$1standby\$1streaming\$1delay | (ms) Sets the maximum delay before canceling queries when a hot standby server is processing streamed WAL data. | 14000 |
| max\$1sync\$1workers\$1per\$1subscription | Maximum number of synchronization workers per subscription | 2 |
| max\$1wal\$1senders | Sets the maximum number of simultaneously running WAL sender processes. | 10 |
| max\$1worker\$1processes | Sets the maximum number of concurrent worker processes. | GREATEST(\$1DBInstanceVCPU\$12,8) |
| min\$1dynamic\$1shared\$1memory | (MB) Amount of dynamic shared memory reserved at startup. | – |
| min\$1parallel\$1index\$1scan\$1size | (8kB) Sets the minimum amount of index data for a parallel scan. | – |
| min\$1parallel\$1table\$1scan\$1size | (8kB) Sets the minimum amount of table data for a parallel scan. | – |
| old\$1snapshot\$1threshold | (min) Time before a snapshot is too old to read pages changed after the snapshot was taken. | – |
| orafce.nls\$1date\$1format | Emulate oracles date output behaviour. | – |
| orafce.timezone | Specify timezone used for sysdate function. | – |
| parallel\$1leader\$1participation | Controls whether Gather and Gather Merge also run subplans. | – |
| parallel\$1setup\$1cost | Sets the planners estimate of the cost of starting up worker processes for parallel query. | – |
| parallel\$1tuple\$1cost | Sets the planners estimate of the cost of passing each tuple (row) from worker to master backend. | – |
| password\$1encryption | Encrypt passwords. | – |
| pgaudit.log | Specifies which classes of statements will be logged by session audit logging. | – |
| pgaudit.log\$1catalog | Specifies that session logging should be enabled in the case where all relations in a statement are in pg\$1catalog. | – |
| pgaudit.log\$1level | Specifies the log level that will be used for log entries. | – |
| pgaudit.log\$1parameter | Specifies that audit logging should include the parameters that were passed with the statement. | – |
| pgaudit.log\$1relation | Specifies whether session audit logging should create a separate log entry for each relation (TABLE, VIEW, etc.) referenced in a SELECT or DML statement. | – |
| pgaudit.log\$1statement\$1once | Specifies whether logging will include the statement text and parameters with the first log entry for a statement/substatement combination or with every entry. | – |
| pgaudit.role | Specifies the master role to use for object audit logging. | – |
| pg\$1bigm.enable\$1recheck | It specifies whether to perform Recheck which is an internal process of full text search. | on |
| pg\$1bigm.gin\$1key\$1limit | It specifies the maximum number of 2-grams of the search keyword to be used for full text search. | 0 |
| pg\$1bigm.last\$1update | It reports the last updated date of the pg\$1bigm module. | 2013.11.22 |
| pg\$1bigm.similarity\$1limit | It specifies the minimum threshold used by the similarity search. | 0.3 |
| pg\$1hint\$1plan.debug\$1print | Logs results of hint parsing. | – |
| pg\$1hint\$1plan.enable\$1hint | Force planner to use plans specified in the hint comment preceding to the query. | – |
| pg\$1hint\$1plan.enable\$1hint\$1table | Force planner to not get hint by using table lookups. | – |
| pg\$1hint\$1plan.message\$1level | Message level of debug messages. | – |
| pg\$1hint\$1plan.parse\$1messages | Message level of parse errors. | – |
| pglogical.batch\$1inserts | Batch inserts if possible | – |
| pglogical.conflict\$1log\$1level | Sets log level used for logging resolved conflicts. | – |
| pglogical.conflict\$1resolution | Sets method used for conflict resolution for resolvable conflicts. | – |
| pglogical.extra\$1connection\$1options | connection options to add to all peer node connections | – |
| pglogical.synchronous\$1commit | pglogical specific synchronous commit value | – |
| pglogical.use\$1spi | Use SPI instead of low-level API for applying changes | – |
| pgtle.clientauth\$1databases\$1to\$1skip | List of databases to skip for clientauth feature. | – |
| pgtle.clientauth\$1db\$1name | Controls which database is used for clientauth feature. | – |
| pgtle.clientauth\$1num\$1parallel\$1workers | Number of background workers used for clientauth feature. | – |
| pgtle.clientauth\$1users\$1to\$1skip | List of users to skip for clientauth feature. | – |
| pgtle.enable\$1clientauth | Enables the clientauth feature. | – |
| pgtle.passcheck\$1db\$1name | Sets which database is used for cluster-wide passcheck feature. | – |
| pg\$1prewarm.autoprewarm | Starts the autoprewarm worker. | – |
| pg\$1prewarm.autoprewarm\$1interval | Sets the interval between dumps of shared buffers | – |
| pg\$1similarity.block\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.block\$1threshold | Sets the threshold used by the Block similarity function. | – |
| pg\$1similarity.block\$1tokenizer | Sets the tokenizer for Block similarity function. | – |
| pg\$1similarity.cosine\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.cosine\$1threshold | Sets the threshold used by the Cosine similarity function. | – |
| pg\$1similarity.cosine\$1tokenizer | Sets the tokenizer for Cosine similarity function. | – |
| pg\$1similarity.dice\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.dice\$1threshold | Sets the threshold used by the Dice similarity measure. | – |
| pg\$1similarity.dice\$1tokenizer | Sets the tokenizer for Dice similarity measure. | – |
| pg\$1similarity.euclidean\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.euclidean\$1threshold | Sets the threshold used by the Euclidean similarity measure. | – |
| pg\$1similarity.euclidean\$1tokenizer | Sets the tokenizer for Euclidean similarity measure. | – |
| pg\$1similarity.hamming\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.hamming\$1threshold | Sets the threshold used by the Block similarity metric. | – |
| pg\$1similarity.jaccard\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.jaccard\$1threshold | Sets the threshold used by the Jaccard similarity measure. | – |
| pg\$1similarity.jaccard\$1tokenizer | Sets the tokenizer for Jaccard similarity measure. | – |
| pg\$1similarity.jaro\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.jaro\$1threshold | Sets the threshold used by the Jaro similarity measure. | – |
| pg\$1similarity.jarowinkler\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.jarowinkler\$1threshold | Sets the threshold used by the Jarowinkler similarity measure. | – |
| pg\$1similarity.levenshtein\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.levenshtein\$1threshold | Sets the threshold used by the Levenshtein similarity measure. | – |
| pg\$1similarity.matching\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.matching\$1threshold | Sets the threshold used by the Matching Coefficient similarity measure. | – |
| pg\$1similarity.matching\$1tokenizer | Sets the tokenizer for Matching Coefficient similarity measure. | – |
| pg\$1similarity.mongeelkan\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.mongeelkan\$1threshold | Sets the threshold used by the Monge-Elkan similarity measure. | – |
| pg\$1similarity.mongeelkan\$1tokenizer | Sets the tokenizer for Monge-Elkan similarity measure. | – |
| pg\$1similarity.nw\$1gap\$1penalty | Sets the gap penalty used by the Needleman-Wunsch similarity measure. | – |
| pg\$1similarity.nw\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.nw\$1threshold | Sets the threshold used by the Needleman-Wunsch similarity measure. | – |
| pg\$1similarity.overlap\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.overlap\$1threshold | Sets the threshold used by the Overlap Coefficient similarity measure. | – |
| pg\$1similarity.overlap\$1tokenizer | Sets the tokenizer for Overlap Coefficientsimilarity measure. | – |
| pg\$1similarity.qgram\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.qgram\$1threshold | Sets the threshold used by the Q-Gram similarity measure. | – |
| pg\$1similarity.qgram\$1tokenizer | Sets the tokenizer for Q-Gram measure. | – |
| pg\$1similarity.swg\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.swg\$1threshold | Sets the threshold used by the Smith-Waterman-Gotoh similarity measure. | – |
| pg\$1similarity.sw\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.sw\$1threshold | Sets the threshold used by the Smith-Waterman similarity measure. | – |
| pg\$1stat\$1statements.max | Sets the maximum number of statements tracked by pg\$1stat\$1statements. | – |
| pg\$1stat\$1statements.save | Save pg\$1stat\$1statements statistics across server shutdowns. | – |
| pg\$1stat\$1statements.track | Selects which statements are tracked by pg\$1stat\$1statements. | – |
| pg\$1stat\$1statements.track\$1planning | Selects whether planning duration is tracked by pg\$1stat\$1statements. | – |
| pg\$1stat\$1statements.track\$1utility | Selects whether utility commands are tracked by pg\$1stat\$1statements. | – |
| plan\$1cache\$1mode | Controls the planner selection of custom or generic plan. | – |
| port | Sets the TCP port the server listens on. | EndPointPort |
| postgis.gdal\$1enabled\$1drivers | Enable or disable GDAL drivers used with PostGIS in Postgres 9.3.5 and above. | ENABLE\$1ALL |
| quote\$1all\$1identifiers | When generating SQL fragments, quote all identifiers. | – |
| random\$1page\$1cost | Sets the planners estimate of the cost of a nonsequentially fetched disk page. | – |
| rdkit.dice\$1threshold | Lower threshold of Dice similarity. Molecules with similarity lower than threshold are not similar by \$1 operation. | – |
| rdkit.do\$1chiral\$1sss | Should stereochemistry be taken into account in substructure matching. If false, no stereochemistry information is used in substructure matches. | – |
| rdkit.tanimoto\$1threshold | Lower threshold of Tanimoto similarity. Molecules with similarity lower than threshold are not similar by % operation. | – |
| rds.accepted\$1password\$1auth\$1method | Force authentication for connections with password stored locally. | md5\$1scram |
| rds.adaptive\$1autovacuum | RDS parameter to enable/disable adaptive autovacuum. | 1 |
| rds.babelfish\$1status | RDS parameter to enable/disable Babelfish for Aurora PostgreSQL. | off |
| rds.enable\$1plan\$1management | Enable or disable the apg\$1plan\$1mgmt extension. | 0 |
| rds.extensions | List of extensions provided by RDS | address\$1standardizer, address\$1standardizer\$1data\$1us, apg\$1plan\$1mgmt, aurora\$1stat\$1utils, amcheck, autoinc, aws\$1commons, aws\$1ml, aws\$1s3, aws\$1lambda, bool\$1plperl, bloom, btree\$1gin, btree\$1gist, citext, cube, dblink, dict\$1int, dict\$1xsyn, earthdistance, fuzzystrmatch, hll, hstore, hstore\$1plperl, insert\$1username, intagg, intarray, ip4r, isn, jsonb\$1plperl, lo, log\$1fdw, ltree, moddatetime, old\$1snapshot, oracle\$1fdw, orafce, pgaudit, pgcrypto, pglogical, pgrouting, pgrowlocks, pgstattuple, pgtap, pg\$1bigm, pg\$1buffercache, pg\$1cron, pg\$1freespacemap, pg\$1hint\$1plan, pg\$1partman, pg\$1prewarm, pg\$1proctab, pg\$1repack, pg\$1similarity, pg\$1stat\$1statements, pg\$1trgm, pg\$1visibility, plcoffee, plls, plperl, plpgsql, plprofiler, pltcl, plv8, postgis, postgis\$1tiger\$1geocoder, postgis\$1raster, postgis\$1topology, postgres\$1fdw, prefix, rdkit, rds\$1tools, refint, sslinfo, tablefunc, tds\$1fdw, test\$1parser, tsm\$1system\$1rows, tsm\$1system\$1time, unaccent, uuid-ossp |
| rds.force\$1admin\$1logging\$1level | See log messages for RDS admin user actions in customer databases. | – |
| rds.force\$1autovacuum\$1logging\$1level | See log messages related to autovacuum operations. | WARNING |
| rds.force\$1ssl | Force SSL connections. | 0 |
| rds.global\$1db\$1rpo | (s) Recovery point objective threshold, in seconds, that blocks user commits when it is violated. This parameter is meant for Aurora PostgreSQL-based global databases. For a nonglobal database, leave it at the default value. For more information about using this parameter, see [Managing RPOs for Aurora PostgreSQL–based global databases](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery). | – |
| rds.logical\$1replication | Enables logical decoding. | 0 |
| rds.logically\$1replicate\$1unlogged\$1tables | Unlogged tables are logically replicated. | 1 |
| rds.log\$1retention\$1period | Amazon RDS will delete PostgreSQL log that are older than N minutes. | 4320 |
| rds.pg\$1stat\$1ramdisk\$1size | Size of the stats ramdisk in MB. A nonzero value will setup the ramdisk. This parameter is only available in Aurora PostgreSQL 14 and lower versions. | 0 |
| rds.rds\$1superuser\$1reserved\$1connections | Sets the number of connection slots reserved for rds\$1superusers. This parameter is only available in versions 15 and earlier. For more information, see the PostgreSQL documentation [reserved connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). | 2 |
| rds.restrict\$1password\$1commands | restricts password-related commands to members of rds\$1password | – |
| rds.superuser\$1variables | List of superuser-only variables for which we elevate rds\$1superuser modification statements. | session\$1replication\$1role |
| recovery\$1init\$1sync\$1method | Sets the method for synchronizing the data directory before crash recovery. | syncfs |
| remove\$1temp\$1files\$1after\$1crash | Remove temporary files after backend crash. | 0 |
| restart\$1after\$1crash | Reinitialize server after backend crash. | – |
| row\$1security | Enable row security. | – |
| search\$1path | Sets the schema search order for names that are not schema-qualified. | – |
| seq\$1page\$1cost | Sets the planners estimate of the cost of a sequentially fetched disk page. | – |
| session\$1replication\$1role | Sets the sessions behavior for triggers and rewrite rules. | – |
| shared\$1buffers | (8kB) Sets the number of shared memory buffers used by the server. | SUM(DBInstanceClassMemory/12038,-50003) |
| shared\$1preload\$1libraries | Lists shared libraries to preload into server. | pg\$1stat\$1statements |
| ssl | Enables SSL connections. | 1 |
| ssl\$1ca\$1file | Location of the SSL server authority file. | /rdsdbdata/rds-metadata/ca-cert.pem |
| ssl\$1cert\$1file | Location of the SSL server certificate file. | /rdsdbdata/rds-metadata/server-cert.pem |
| ssl\$1ciphers | Sets the list of allowed TLS ciphers to be used on secure connections. | – |
| ssl\$1crl\$1dir | Location of the SSL certificate revocation list directory. | /rdsdbdata/rds-metadata/ssl\$1crl\$1dir/ |
| ssl\$1key\$1file | Location of the SSL server private key file | /rdsdbdata/rds-metadata/server-key.pem |
| ssl\$1max\$1protocol\$1version | Sets the maximum SSL/TLS protocol version allowed | – |
| ssl\$1min\$1protocol\$1version | Sets the minimum SSL/TLS protocol version allowed | TLSv1.2 |
| standard\$1conforming\$1strings | Causes ... strings to treat backslashes literally. | – |
| statement\$1timeout | (ms) Sets the maximum allowed duration of any statement. | – |
| stats\$1temp\$1directory | Writes temporary statistics files to the specified directory. | /rdsdbdata/db/pg\$1stat\$1tmp |
| superuser\$1reserved\$1connections | Sets the number of connection slots reserved for superusers. | 3 |
| synchronize\$1seqscans | Enable synchronized sequential scans. | – |
| synchronous\$1commit | Sets the current transactions synchronization level. | on |
| tcp\$1keepalives\$1count | Maximum number of TCP keepalive retransmits. | – |
| tcp\$1keepalives\$1idle | (s) Time between issuing TCP keepalives. | – |
| tcp\$1keepalives\$1interval | (s) Time between TCP keepalive retransmits. | – |
| temp\$1buffers | (8kB) Sets the maximum number of temporary buffers used by each session. | – |
| temp\$1file\$1limit | Constrains the total amount disk space in kilobytes that a given PostgreSQL process can use for temporary files, excluding space used for explicit temporary tables | -1 |
| temp\$1tablespaces | Sets the tablespace(s) to use for temporary tables and sort files. | – |
| timezone | Sets the time zone for displaying and interpreting time stamps. | UTC |
| track\$1activities | Collects information about executing commands. | – |
| track\$1activity\$1query\$1size | Sets the size reserved for pg\$1stat\$1activity.current\$1query, in bytes. | 4096 |
| track\$1commit\$1timestamp | Collects transaction commit time. | – |
| track\$1counts | Collects statistics on database activity. | – |
| track\$1functions | Collects function-level statistics on database activity. | pl |
| track\$1io\$1timing | Collects timing statistics on database IO activity. | 1 |
| track\$1wal\$1io\$1timing | Collects timing statistics for WAL I/O activity. | – |
| transform\$1null\$1equals | Treats expr=NULL as expr IS NULL. | – |
| update\$1process\$1title | Updates the process title to show the active SQL command. | – |
| vacuum\$1cost\$1delay | (ms) Vacuum cost delay in milliseconds. | – |
| vacuum\$1cost\$1limit | Vacuum cost amount available before napping. | – |
| vacuum\$1cost\$1page\$1dirty | Vacuum cost for a page dirtied by vacuum. | – |
| vacuum\$1cost\$1page\$1hit | Vacuum cost for a page found in the buffer cache. | – |
| vacuum\$1cost\$1page\$1miss | Vacuum cost for a page not found in the buffer cache. | 0 |
| vacuum\$1defer\$1cleanup\$1age | Number of transactions by which VACUUM and HOT cleanup should be deferred, if any. | – |
| vacuum\$1failsafe\$1age | Age at which VACUUM should trigger failsafe to avoid a wraparound outage. | 1200000000 |
| vacuum\$1freeze\$1min\$1age | Minimum age at which VACUUM should freeze a table row. | – |
| vacuum\$1freeze\$1table\$1age | Age at which VACUUM should scan whole table to freeze tuples. | – |
| vacuum\$1multixact\$1failsafe\$1age | Multixact age at which VACUUM should trigger failsafe to avoid a wraparound outage. | 1200000000 |
| vacuum\$1multixact\$1freeze\$1min\$1age | Minimum age at which VACUUM should freeze a MultiXactId in a table row. | – |
| vacuum\$1multixact\$1freeze\$1table\$1age | Multixact age at which VACUUM should scan whole table to freeze tuples. | – |
| wal\$1buffers | (8kB) Sets the number of disk-page buffers in shared memory for WAL. | – |
| wal\$1receiver\$1create\$1temp\$1slot | Sets whether a WAL receiver should create a temporary replication slot if no permanent slot is configured. | 0 |
| wal\$1receiver\$1status\$1interval | (s) Sets the maximum interval between WAL receiver status reports to the primary. | – |
| wal\$1receiver\$1timeout | (ms) Sets the maximum wait time to receive data from the primary. | 30000 |
| wal\$1sender\$1timeout | (ms) Sets the maximum time to wait for WAL replication. | – |
| work\$1mem | (kB) Sets the maximum memory to be used for query workspaces. | – |
| xmlbinary | Sets how binary values are to be encoded in XML. | – |
| xmloption | Sets whether XML data in implicit parsing and serialization operations is to be considered as documents or content fragments. | – |
## Aurora PostgreSQL instance-level parameters
You can view the instance-level parameters available for a specific Aurora PostgreSQL version using the AWS Management console, the AWS CLI, or the Amazon RDS API. For information about viewing the parameters in an Aurora PostgreSQL DB parameter groups in the RDS console, see [Viewing parameter values for a DB parameter group in Amazon Aurora](USER_WorkingWithParamGroups.Viewing.md).
Some instance-level parameters aren't available in all versions and some are being deprecated. For information about viewing the parameters of a specific Aurora PostgreSQL version, see [Viewing Aurora PostgreSQL DB cluster and DB parameters](#AuroraPostgreSQL.Reference.ParameterGroups-viewing-parameters).
For example, the following table lists the parameters that apply to a specific DB instance in an Aurora PostgreSQL DB cluster. This list was generated by running the [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI command with `default.aurora-postgresql14` for the `--db-parameter-group-name` value.
For a listing of the DB cluster parameters for this same default DB parameter group, see [Aurora PostgreSQL cluster-level parameters](#AuroraPostgreSQL.Reference.Parameters.Cluster).
| Parameter name | Description | Default |
| --- | --- | --- |
| apg\$1enable\$1batch\$1mode\$1function\$1execution | Enables batch-mode functions to process sets of rows at a time. | – |
| apg\$1enable\$1correlated\$1any\$1transform | Enables the planner to transform correlated ANY Sublink (IN/NOT IN subquery to JOIN when possible. | – |
| apg\$1enable\$1function\$1migration | Enables the planner to migrate eligible scalar functions to the FROM clause. | – |
| apg\$1enable\$1not\$1in\$1transform | Enables the planner to transform NOT IN subquery to ANTI JOIN when possible. | – |
| apg\$1enable\$1remove\$1redundant\$1inner\$1joins | Enables the planner to remove redundant inner joins. | – |
| apg\$1enable\$1semijoin\$1push\$1down | Enables the use of semijoin filters for hash joins. | – |
| apg\$1plan\$1mgmt.capture\$1plan\$1baselines | Capture plan baseline mode. manual - enable plan capture for any SQL statement, off - disable plan capture, automatic - enable plan capture for for statements in pg\$1stat\$1statements that satisfy the eligibility criteria. | off |
| apg\$1plan\$1mgmt.max\$1databases | Sets the maximum number of databases that that may manage queries using apg\$1plan\$1mgmt. | 10 |
| apg\$1plan\$1mgmt.max\$1plans | Sets the maximum number of plans that may be cached by apg\$1plan\$1mgmt. | 10000 |
| apg\$1plan\$1mgmt.plan\$1retention\$1period | Maximum number of days since a plan was last\$1used before a plan will be automatically deleted. | 32 |
| apg\$1plan\$1mgmt.unapproved\$1plan\$1execution\$1threshold | Estimated total plan cost below which an Unapproved plan will be executed. | 0 |
| apg\$1plan\$1mgmt.use\$1plan\$1baselines | Use only approved or fixed plans for managed statements. | false |
| application\$1name | Sets the application name to be reported in statistics and logs. | – |
| aurora\$1compute\$1plan\$1id | Monitors query execution plans to detect the execution plans contributing to current database load and to track performance statistics of execution plans over time. For more information, see [Monitoring query execution plans for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Monitoring.Query.Plans.html). | on |
| aurora\$1temp\$1space\$1size | (MB) Sets size of the allocated space for Optimized Reads-enabled temporary objects on Aurora I/O-Optimized clusters with supported instance classes. | DBInstanceClassMemory/524288 |
| authentication\$1timeout | (s Sets the maximum allowed time to complete client authentication. | – |
| auto\$1explain.log\$1analyze | Use EXPLAIN ANALYZE for plan logging. | – |
| auto\$1explain.log\$1buffers | Log buffers usage. | – |
| auto\$1explain.log\$1format | EXPLAIN format to be used for plan logging. | – |
| auto\$1explain.log\$1min\$1duration | Sets the minimum execution time above which plans will be logged. | – |
| auto\$1explain.log\$1nested\$1statements | Log nested statements. | – |
| auto\$1explain.log\$1timing | Collect timing data, not just row counts. | – |
| auto\$1explain.log\$1triggers | Include trigger statistics in plans. | – |
| auto\$1explain.log\$1verbose | Use EXPLAIN VERBOSE for plan logging. | – |
| auto\$1explain.sample\$1rate | Fraction of queries to process. | – |
| babelfishpg\$1tds.listen\$1addresses | Sets the host name or IP address(es to listen TDS to. | \$1 |
| babelfishpg\$1tds.tds\$1debug\$1log\$1level | Sets logging level in TDS, 0 disables logging | 1 |
| backend\$1flush\$1after | (8Kb Number of pages after which previously performed writes are flushed to disk. | – |
| bytea\$1output | Sets the output format for bytea. | – |
| check\$1function\$1bodies | Check function bodies during CREATE FUNCTION. | – |
| client\$1connection\$1check\$1interval | Sets the time interval between checks for disconnection while running queries. | – |
| client\$1min\$1messages | Sets the message levels that are sent to the client. | – |
| config\$1file | Sets the servers main configuration file. | /rdsdbdata/config/postgresql.conf |
| constraint\$1exclusion | Enables the planner to use constraints to optimize queries. | – |
| cpu\$1index\$1tuple\$1cost | Sets the planners estimate of the cost of processing each index entry during an index scan. | – |
| cpu\$1operator\$1cost | Sets the planners estimate of the cost of processing each operator or function call. | – |
| cpu\$1tuple\$1cost | Sets the planners estimate of the cost of processing each tuple (row. | – |
| cron.database\$1name | Sets the database to store pg\$1cron metadata tables | postgres |
| cron.log\$1run | Log all jobs runs into the job\$1run\$1details table | on |
| cron.log\$1statement | Log all cron statements prior to execution. | off |
| cron.max\$1running\$1jobs | Maximum number of jobs that can run concurrently. | 5 |
| cron.use\$1background\$1workers | Enables background workers for pg\$1cron | on |
| cursor\$1tuple\$1fraction | Sets the planners estimate of the fraction of a cursors rows that will be retrieved. | – |
| db\$1user\$1namespace | Enables per-database user names. | – |
| deadlock\$1timeout | (ms Sets the time to wait on a lock before checking for deadlock. | – |
| debug\$1pretty\$1print | Indents parse and plan tree displays. | – |
| debug\$1print\$1parse | Logs each querys parse tree. | – |
| debug\$1print\$1plan | Logs each querys execution plan. | – |
| debug\$1print\$1rewritten | Logs each querys rewritten parse tree. | – |
| default\$1statistics\$1target | Sets the default statistics target. | – |
| default\$1transaction\$1deferrable | Sets the default deferrable status of new transactions. | – |
| default\$1transaction\$1isolation | Sets the transaction isolation level of each new transaction. | – |
| default\$1transaction\$1read\$1only | Sets the default read-only status of new transactions. | – |
| effective\$1cache\$1size | (8kB Sets the planners assumption about the size of the disk cache. | SUM(DBInstanceClassMemory/12038,-50003 |
| effective\$1io\$1concurrency | Number of simultaneous requests that can be handled efficiently by the disk subsystem. | – |
| enable\$1async\$1append | Enables the planners use of async append plans. | – |
| enable\$1bitmapscan | Enables the planners use of bitmap-scan plans. | – |
| enable\$1gathermerge | Enables the planners use of gather merge plans. | – |
| enable\$1hashagg | Enables the planners use of hashed aggregation plans. | – |
| enable\$1hashjoin | Enables the planners use of hash join plans. | – |
| enable\$1incremental\$1sort | Enables the planners use of incremental sort steps. | – |
| enable\$1indexonlyscan | Enables the planners use of index-only-scan plans. | – |
| enable\$1indexscan | Enables the planners use of index-scan plans. | – |
| enable\$1material | Enables the planners use of materialization. | – |
| enable\$1memoize | Enables the planners use of memoization | – |
| enable\$1mergejoin | Enables the planners use of merge join plans. | – |
| enable\$1nestloop | Enables the planners use of nested-loop join plans. | – |
| enable\$1parallel\$1append | Enables the planners use of parallel append plans. | – |
| enable\$1parallel\$1hash | Enables the planners user of parallel hash plans. | – |
| enable\$1partition\$1pruning | Enable plan-time and run-time partition pruning. | – |
| enable\$1partitionwise\$1aggregate | Enables partitionwise aggregation and grouping. | – |
| enable\$1partitionwise\$1join | Enables partitionwise join. | – |
| enable\$1seqscan | Enables the planners use of sequential-scan plans. | – |
| enable\$1sort | Enables the planners use of explicit sort steps. | – |
| enable\$1tidscan | Enables the planners use of TID scan plans. | – |
| escape\$1string\$1warning | Warn about backslash escapes in ordinary string literals. | – |
| exit\$1on\$1error | Terminate session on any error. | – |
| force\$1parallel\$1mode | Forces use of parallel query facilities. | – |
| from\$1collapse\$1limit | Sets the FROM-list size beyond which subqueries are not collapsed. | – |
| geqo | Enables genetic query optimization. | – |
| geqo\$1effort | GEQO: effort is used to set the default for other GEQO parameters. | – |
| geqo\$1generations | GEQO: number of iterations of the algorithm. | – |
| geqo\$1pool\$1size | GEQO: number of individuals in the population. | – |
| geqo\$1seed | GEQO: seed for random path selection. | – |
| geqo\$1selection\$1bias | GEQO: selective pressure within the population. | – |
| geqo\$1threshold | Sets the threshold of FROM items beyond which GEQO is used. | – |
| gin\$1fuzzy\$1search\$1limit | Sets the maximum allowed result for exact search by GIN. | – |
| gin\$1pending\$1list\$1limit | (kB Sets the maximum size of the pending list for GIN index. | – |
| hash\$1mem\$1multiplier | Multiple of work\$1mem to use for hash tables. | – |
| hba\$1file | Sets the servers hba configuration file. | /rdsdbdata/config/pg\$1hba.conf |
| hot\$1standby\$1feedback | Allows feedback from a hot standby to the primary that will avoid query conflicts. | on |
| ident\$1file | Sets the servers ident configuration file. | /rdsdbdata/config/pg\$1ident.conf |
| idle\$1in\$1transaction\$1session\$1timeout | (ms Sets the maximum allowed duration of any idling transaction. | 86400000 |
| idle\$1session\$1timeout | Terminate any session that has been idle (that is, waiting for a client query, but not within an open transaction, for longer than the specified amount of time | – |
| join\$1collapse\$1limit | Sets the FROM-list size beyond which JOIN constructs are not flattened. | – |
| lc\$1messages | Sets the language in which messages are displayed. | – |
| listen\$1addresses | Sets the host name or IP address(es to listen to. | \$1 |
| lo\$1compat\$1privileges | Enables backward compatibility mode for privilege checks on large objects. | 0 |
| log\$1connections | Logs each successful connection. | – |
| log\$1destination | Sets the destination for server log output. | stderr |
| log\$1directory | Sets the destination directory for log files. | /rdsdbdata/log/error |
| log\$1disconnections | Logs end of a session, including duration. | – |
| log\$1duration | Logs the duration of each completed SQL statement. | – |
| log\$1error\$1verbosity | Sets the verbosity of logged messages. | – |
| log\$1executor\$1stats | Writes executor performance statistics to the server log. | – |
| log\$1file\$1mode | Sets the file permissions for log files. | 0644 |
| log\$1filename | Sets the file name pattern for log files. | postgresql.log.%Y-%m-%d-%H%M |
| logging\$1collector | Start a subprocess to capture stderr output and/or csvlogs into log files. | 1 |
| log\$1hostname | Logs the host name in the connection logs. | 0 |
| logical\$1decoding\$1work\$1mem | (kB This much memory can be used by each internal reorder buffer before spilling to disk. | – |
| log\$1line\$1prefix | Controls information prefixed to each log line. | %t:%r:%u@%d:%p]: |
| log\$1lock\$1waits | Logs long lock waits. | – |
| log\$1min\$1duration\$1sample | (ms Sets the minimum execution time above which a sample of statements will be logged. Sampling is determined by log\$1statement\$1sample\$1rate. | – |
| log\$1min\$1duration\$1statement | (ms Sets the minimum execution time above which statements will be logged. | – |
| log\$1min\$1error\$1statement | Causes all statements generating error at or above this level to be logged. | – |
| log\$1min\$1messages | Sets the message levels that are logged. | – |
| log\$1parameter\$1max\$1length | (B When logging statements, limit logged parameter values to first N bytes. | – |
| log\$1parameter\$1max\$1length\$1on\$1error | (B When reporting an error, limit logged parameter values to first N bytes. | – |
| log\$1parser\$1stats | Writes parser performance statistics to the server log. | – |
| log\$1planner\$1stats | Writes planner performance statistics to the server log. | – |
| log\$1replication\$1commands | Logs each replication command. | – |
| log\$1rotation\$1age | (min Automatic log file rotation will occur after N minutes. | 60 |
| log\$1rotation\$1size | (kB Automatic log file rotation will occur after N kilobytes. | 100000 |
| log\$1statement | Sets the type of statements logged. | – |
| log\$1statement\$1sample\$1rate | Fraction of statements exceeding log\$1min\$1duration\$1sample to be logged. | – |
| log\$1statement\$1stats | Writes cumulative performance statistics to the server log. | – |
| log\$1temp\$1files | (kB Log the use of temporary files larger than this number of kilobytes. | – |
| log\$1timezone | Sets the time zone to use in log messages. | UTC |
| log\$1truncate\$1on\$1rotation | Truncate existing log files of same name during log rotation. | 0 |
| maintenance\$1io\$1concurrency | A variant of effective\$1io\$1concurrency that is used for maintenance work. | 1 |
| maintenance\$1work\$1mem | (kB Sets the maximum memory to be used for maintenance operations. | GREATEST(DBInstanceClassMemory/63963136\$11024,65536 |
| max\$1connections | Sets the maximum number of concurrent connections. | LEAST(DBInstanceClassMemory/9531392,5000 |
| max\$1files\$1per\$1process | Sets the maximum number of simultaneously open files for each server process. | – |
| max\$1locks\$1per\$1transaction | Sets the maximum number of locks per transaction. | 64 |
| max\$1parallel\$1maintenance\$1workers | Sets the maximum number of parallel processes per maintenance operation. | – |
| max\$1parallel\$1workers | Sets the maximum number of parallel workers than can be active at one time. | GREATEST(\$1DBInstanceVCPU/2,8 |
| max\$1parallel\$1workers\$1per\$1gather | Sets the maximum number of parallel processes per executor node. | – |
| max\$1pred\$1locks\$1per\$1page | Sets the maximum number of predicate-locked tuples per page. | – |
| max\$1pred\$1locks\$1per\$1relation | Sets the maximum number of predicate-locked pages and tuples per relation. | – |
| max\$1pred\$1locks\$1per\$1transaction | Sets the maximum number of predicate locks per transaction. | – |
| max\$1slot\$1wal\$1keep\$1size | (MB Replication slots will be marked as failed, and segments released for deletion or recycling, if this much space is occupied by WAL on disk. | – |
| max\$1stack\$1depth | (kB Sets the maximum stack depth, in kilobytes. | 6144 |
| max\$1standby\$1streaming\$1delay | (ms Sets the maximum delay before canceling queries when a hot standby server is processing streamed WAL data. | 14000 |
| max\$1worker\$1processes | Sets the maximum number of concurrent worker processes. | GREATEST(\$1DBInstanceVCPU\$12,8 |
| min\$1dynamic\$1shared\$1memory | (MB Amount of dynamic shared memory reserved at startup. | – |
| min\$1parallel\$1index\$1scan\$1size | (8kB Sets the minimum amount of index data for a parallel scan. | – |
| min\$1parallel\$1table\$1scan\$1size | (8kB Sets the minimum amount of table data for a parallel scan. | – |
| old\$1snapshot\$1threshold | (min Time before a snapshot is too old to read pages changed after the snapshot was taken. | – |
| parallel\$1leader\$1participation | Controls whether Gather and Gather Merge also run subplans. | – |
| parallel\$1setup\$1cost | Sets the planners estimate of the cost of starting up worker processes for parallel query. | – |
| parallel\$1tuple\$1cost | Sets the planners estimate of the cost of passing each tuple (row from worker to master backend. | – |
| pgaudit.log | Specifies which classes of statements will be logged by session audit logging. | – |
| pgaudit.log\$1catalog | Specifies that session logging should be enabled in the case where all relations in a statement are in pg\$1catalog. | – |
| pgaudit.log\$1level | Specifies the log level that will be used for log entries. | – |
| pgaudit.log\$1parameter | Specifies that audit logging should include the parameters that were passed with the statement. | – |
| pgaudit.log\$1relation | Specifies whether session audit logging should create a separate log entry for each relation (TABLE, VIEW, etc. referenced in a SELECT or DML statement. | – |
| pgaudit.log\$1statement\$1once | Specifies whether logging will include the statement text and parameters with the first log entry for a statement/substatement combination or with every entry. | – |
| pgaudit.role | Specifies the master role to use for object audit logging. | – |
| pg\$1bigm.enable\$1recheck | It specifies whether to perform Recheck which is an internal process of full text search. | on |
| pg\$1bigm.gin\$1key\$1limit | It specifies the maximum number of 2-grams of the search keyword to be used for full text search. | 0 |
| pg\$1bigm.last\$1update | It reports the last updated date of the pg\$1bigm module. | 2013.11.22 |
| pg\$1bigm.similarity\$1limit | It specifies the minimum threshold used by the similarity search. | 0.3 |
| pg\$1hint\$1plan.debug\$1print | Logs results of hint parsing. | – |
| pg\$1hint\$1plan.enable\$1hint | Force planner to use plans specified in the hint comment preceding to the query. | – |
| pg\$1hint\$1plan.enable\$1hint\$1table | Force planner to not get hint by using table lookups. | – |
| pg\$1hint\$1plan.message\$1level | Message level of debug messages. | – |
| pg\$1hint\$1plan.parse\$1messages | Message level of parse errors. | – |
| pglogical.batch\$1inserts | Batch inserts if possible | – |
| pglogical.conflict\$1log\$1level | Sets log level used for logging resolved conflicts. | – |
| pglogical.conflict\$1resolution | Sets method used for conflict resolution for resolvable conflicts. | – |
| pglogical.extra\$1connection\$1options | connection options to add to all peer node connections | – |
| pglogical.synchronous\$1commit | pglogical specific synchronous commit value | – |
| pglogical.use\$1spi | Use SPI instead of low-level API for applying changes | – |
| pg\$1similarity.block\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.block\$1threshold | Sets the threshold used by the Block similarity function. | – |
| pg\$1similarity.block\$1tokenizer | Sets the tokenizer for Block similarity function. | – |
| pg\$1similarity.cosine\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.cosine\$1threshold | Sets the threshold used by the Cosine similarity function. | – |
| pg\$1similarity.cosine\$1tokenizer | Sets the tokenizer for Cosine similarity function. | – |
| pg\$1similarity.dice\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.dice\$1threshold | Sets the threshold used by the Dice similarity measure. | – |
| pg\$1similarity.dice\$1tokenizer | Sets the tokenizer for Dice similarity measure. | – |
| pg\$1similarity.euclidean\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.euclidean\$1threshold | Sets the threshold used by the Euclidean similarity measure. | – |
| pg\$1similarity.euclidean\$1tokenizer | Sets the tokenizer for Euclidean similarity measure. | – |
| pg\$1similarity.hamming\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.hamming\$1threshold | Sets the threshold used by the Block similarity metric. | – |
| pg\$1similarity.jaccard\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.jaccard\$1threshold | Sets the threshold used by the Jaccard similarity measure. | – |
| pg\$1similarity.jaccard\$1tokenizer | Sets the tokenizer for Jaccard similarity measure. | – |
| pg\$1similarity.jaro\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.jaro\$1threshold | Sets the threshold used by the Jaro similarity measure. | – |
| pg\$1similarity.jarowinkler\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.jarowinkler\$1threshold | Sets the threshold used by the Jarowinkler similarity measure. | – |
| pg\$1similarity.levenshtein\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.levenshtein\$1threshold | Sets the threshold used by the Levenshtein similarity measure. | – |
| pg\$1similarity.matching\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.matching\$1threshold | Sets the threshold used by the Matching Coefficient similarity measure. | – |
| pg\$1similarity.matching\$1tokenizer | Sets the tokenizer for Matching Coefficient similarity measure. | – |
| pg\$1similarity.mongeelkan\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.mongeelkan\$1threshold | Sets the threshold used by the Monge-Elkan similarity measure. | – |
| pg\$1similarity.mongeelkan\$1tokenizer | Sets the tokenizer for Monge-Elkan similarity measure. | – |
| pg\$1similarity.nw\$1gap\$1penalty | Sets the gap penalty used by the Needleman-Wunsch similarity measure. | – |
| pg\$1similarity.nw\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.nw\$1threshold | Sets the threshold used by the Needleman-Wunsch similarity measure. | – |
| pg\$1similarity.overlap\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.overlap\$1threshold | Sets the threshold used by the Overlap Coefficient similarity measure. | – |
| pg\$1similarity.overlap\$1tokenizer | Sets the tokenizer for Overlap Coefficientsimilarity measure. | – |
| pg\$1similarity.qgram\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.qgram\$1threshold | Sets the threshold used by the Q-Gram similarity measure. | – |
| pg\$1similarity.qgram\$1tokenizer | Sets the tokenizer for Q-Gram measure. | – |
| pg\$1similarity.swg\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.swg\$1threshold | Sets the threshold used by the Smith-Waterman-Gotoh similarity measure. | – |
| pg\$1similarity.sw\$1is\$1normalized | Sets if the result value is normalized or not. | – |
| pg\$1similarity.sw\$1threshold | Sets the threshold used by the Smith-Waterman similarity measure. | – |
| pg\$1stat\$1statements.max | Sets the maximum number of statements tracked by pg\$1stat\$1statements. | – |
| pg\$1stat\$1statements.save | Save pg\$1stat\$1statements statistics across server shutdowns. | – |
| pg\$1stat\$1statements.track | Selects which statements are tracked by pg\$1stat\$1statements. | – |
| pg\$1stat\$1statements.track\$1planning | Selects whether planning duration is tracked by pg\$1stat\$1statements. | – |
| pg\$1stat\$1statements.track\$1utility | Selects whether utility commands are tracked by pg\$1stat\$1statements. | – |
| postgis.gdal\$1enabled\$1drivers | Enable or disable GDAL drivers used with PostGIS in Postgres 9.3.5 and above. | ENABLE\$1ALL |
| quote\$1all\$1identifiers | When generating SQL fragments, quote all identifiers. | – |
| random\$1page\$1cost | Sets the planners estimate of the cost of a nonsequentially fetched disk page. | – |
| rds.enable\$1memory\$1management | Improves memory management capabilities in Aurora PostgreSQL 12.17, 13.13, 14.10, 15.5, and higher versions that prevents stability issues and database restarts caused by insufficient free memory. For more information, see [Improved memory management in Aurora PostgreSQLLimitation](AuroraPostgreSQL.BestPractices.memory.management.md). | True |
| rds.force\$1admin\$1logging\$1level | See log messages for RDS admin user actions in customer databases. | – |
| rds.log\$1retention\$1period | Amazon RDS will delete PostgreSQL log that are older than N minutes. | 4320 |
| rds.memory\$1allocation\$1guard | Improves memory management capabilities in Aurora PostgreSQL 11.21, 12.16, 13.12, 14.9, 15.4, and older versions that prevents stability issues and database restarts caused by insufficient free memory. For more information, see [Improved memory management in Aurora PostgreSQLLimitation](AuroraPostgreSQL.BestPractices.memory.management.md). | False |
| rds.pg\$1stat\$1ramdisk\$1size | Size of the stats ramdisk in MB. A nonzero value will setup the ramdisk. | 0 |
| rds.rds\$1superuser\$1reserved\$1connections | Sets the number of connection slots reserved for rds\$1superusers. This parameter is only available in versions 15 and earlier. For more information, see the PostgreSQL documentation [reserved connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). | 2 |
| rds.superuser\$1variables | List of superuser-only variables for which we elevate rds\$1superuser modification statements. | session\$1replication\$1role |
| remove\$1temp\$1files\$1after\$1crash | Remove temporary files after backend crash. | 0 |
| restart\$1after\$1crash | Reinitialize server after backend crash. | – |
| row\$1security | Enable row security. | – |
| search\$1path | Sets the schema search order for names that are not schema-qualified. | – |
| seq\$1page\$1cost | Sets the planners estimate of the cost of a sequentially fetched disk page. | – |
| session\$1replication\$1role | Sets the sessions behavior for triggers and rewrite rules. | – |
| shared\$1buffers | (8kB) Sets the number of shared memory buffers used by the server. | SUM(DBInstanceClassMemory/12038,-50003) |
| shared\$1preload\$1libraries | Lists shared libraries to preload into server. | pg\$1stat\$1statements |
| ssl\$1ca\$1file | Location of the SSL server authority file. | /rdsdbdata/rds-metadata/ca-cert.pem |
| ssl\$1cert\$1file | Location of the SSL server certificate file. | /rdsdbdata/rds-metadata/server-cert.pem |
| ssl\$1crl\$1dir | Location of the SSL certificate revocation list directory. | /rdsdbdata/rds-metadata/ssl\$1crl\$1dir/ |
| ssl\$1key\$1file | Location of the SSL server private key file | /rdsdbdata/rds-metadata/server-key.pem |
| standard\$1conforming\$1strings | Causes ... strings to treat backslashes literally. | – |
| statement\$1timeout | (ms Sets the maximum allowed duration of any statement. | – |
| stats\$1temp\$1directory | Writes temporary statistics files to the specified directory. | /rdsdbdata/db/pg\$1stat\$1tmp |
| superuser\$1reserved\$1connections | Sets the number of connection slots reserved for superusers. | 3 |
| synchronize\$1seqscans | Enable synchronized sequential scans. | – |
| tcp\$1keepalives\$1count | Maximum number of TCP keepalive retransmits. | – |
| tcp\$1keepalives\$1idle | (s Time between issuing TCP keepalives. | – |
| tcp\$1keepalives\$1interval | (s Time between TCP keepalive retransmits. | – |
| temp\$1buffers | (8kB Sets the maximum number of temporary buffers used by each session. | – |
| temp\$1file\$1limit | Constrains the total amount disk space in kilobytes that a given PostgreSQL process can use for temporary files, excluding space used for explicit temporary tables | -1 |
| temp\$1tablespaces | Sets the tablespace(s to use for temporary tables and sort files. | – |
| track\$1activities | Collects information about executing commands. | – |
| track\$1activity\$1query\$1size | Sets the size reserved for pg\$1stat\$1activity.current\$1query, in bytes. | 4096 |
| track\$1counts | Collects statistics on database activity. | – |
| track\$1functions | Collects function-level statistics on database activity. | pl |
| track\$1io\$1timing | Collects timing statistics on database IO activity. | 1 |
| transform\$1–\$1equals | Treats expr=– as expr IS –. | – |
| update\$1process\$1title | Updates the process title to show the active SQL command. | – |
| wal\$1receiver\$1status\$1interval | (s Sets the maximum interval between WAL receiver status reports to the primary. | – |
| work\$1mem | (kB Sets the maximum memory to be used for query workspaces. | – |
| xmlbinary | Sets how binary values are to be encoded in XML. | – |
| xmloption | Sets whether XML data in implicit parsing and serialization operations is to be considered as documents or content fragments. | – |
# Amazon Aurora PostgreSQL wait events
The following are common wait events for Aurora PostgreSQL. To learn more about wait events and tuning your Aurora PostgreSQL DB cluster, see [Tuning with wait events for Aurora PostgreSQL](AuroraPostgreSQL.Tuning.md).
**Activity:ArchiverMain**
The archiver process is waiting for activity.
**Activity:AutoVacuumMain**
The autovacuum launcher process is waiting for activity.
**Activity:BgWriterHibernate**
The background writer process is hibernating while waiting for activity.
**Activity:BgWriterMain**
The background writer process is waiting for activity.
**Activity:CheckpointerMain**
The checkpointer process is waiting for activity.
**Activity:LogicalApplyMain**
The logical replication apply process is waiting for activity.
**Activity:LogicalLauncherMain**
The logical replication launcher process is waiting for activity.
**Activity:PgStatMain**
The statistics collector process is waiting for activity.
**Activity:RecoveryWalAll**
A process is waiting for the write-ahead log (WAL) from a stream at recovery.
**Activity:RecoveryWalStream**
The startup process is waiting for the write-ahead log (WAL) to arrive during streaming recovery.
**Activity:SysLoggerMain**
The syslogger process is waiting for activity.
**Activity:WalReceiverMain**
The write-ahead log (WAL) receiver process is waiting for activity.
**Activity:WalSenderMain**
The write-ahead log (WAL) sender process is waiting for activity.
**Activity:WalWriterMain**
The write-ahead log (WAL) writer process is waiting for activity.
**BufferPin:BufferPin**
A process is waiting to acquire an exclusive pin on a buffer.
**Client:GSSOpenServer**
A process is waiting to read data from the client while establishing a Generic Security Service Application Program Interface (GSSAPI) session.
**Client:ClientRead**
A backend process is waiting to receive data from a PostgreSQL client. For more information, see [Client:ClientRead](apg-waits.clientread.md).
**Client:ClientWrite**
A backend process is waiting to send more data to a PostgreSQL client. For more information, see [Client:ClientWrite](apg-waits.clientwrite.md).
**Client:LibPQWalReceiverConnect**
A process is waiting in the write-ahead log (WAL) receiver to establish connection to remote server.
**Client:LibPQWalReceiverReceive**
A process is waiting in the write-ahead log (WAL) receiver to receive data from remote server.
**Client:SSLOpenServer**
A process is waiting for Secure Sockets Layer (SSL) while attempting connection.
**Client:WalReceiverWaitStart**
A process is waiting for startup process to send initial data for streaming replication.
**Client:WalSenderWaitForWAL**
A process is waiting for the write-ahead log (WAL) to be flushed in the WAL sender process.
**Client:WalSenderWriteData**
A process is waiting for any activity when processing replies from the write-ahead log (WAL) receiver in the WAL sender process.
**CPU**
A backend process is active in or is waiting for CPU. For more information, see [CPU](apg-waits.cpu.md).
**Extension:extension**
A backend process is waiting for a condition defined by an extension or module.
**IO:AuroraEnhancedLogicalWALRead**
A backend process is fetching log records from the change data capture (CDC) volume.
**IO:AuroraOptimizedReadsCacheRead**
A process is waiting for a read from Optimized Reads tiered cache because the page isn't available in shared memory.
**IO:AuroraOptimizedReadsCacheSegmentTruncate**
A process is waiting for an Optimized Reads tiered cache segment file to be truncated.
**IO:AuroraOptimizedReadsCacheWrite**
The background writer process is waiting to write in Optimized Reads tiered cache.
**IO:AuroraStorageLogAllocate**
A session is allocating metadata and preparing for a transaction log write.
**IO:BufFileRead**
When operations require more memory than the amount defined by working memory parameters, the engine creates temporary files on disk. This wait event occurs when operations read from the temporary files. For more information, see [IO:BufFileRead and IO:BufFileWrite](apg-waits.iobuffile.md).
**IO:BufFileWrite**
When operations require more memory than the amount defined by working memory parameters, the engine creates temporary files on disk. This wait event occurs when operations write to the temporary files. For more information, see [IO:BufFileRead and IO:BufFileWrite](apg-waits.iobuffile.md).
**IO:ControlFileRead**
A process is waiting for a read from the `pg_control` file.
**IO:ControlFileSync**
A process is waiting for the `pg_control` file to reach durable storage.
**IO:ControlFileSyncUpdate**
A process is waiting for an update to the `pg_control` file to reach durable storage.
**IO:ControlFileWrite**
A process is waiting for a write to the `pg_control` file.
**IO:ControlFileWriteUpdate**
A process is waiting for a write to update the `pg_control` file.
**IO:CopyFileRead**
A process is waiting for a read during a file copy operation.
**IO:CopyFileWrite**
A process is waiting for a write during a file copy operation.
**IO:DataFileExtend**
A process is waiting for a relation data file to be extended.
**IO:DataFileFlush**
A process is waiting for a relation data file to reach durable storage.
**IO:DataFileImmediateSync**
A process is waiting for an immediate synchronization of a relation data file to durable storage.
**IO:DataFilePrefetch**
A process is waiting for an asynchronous prefetch from a relation data file.
**IO:DataFileSync**
A process is waiting for changes to a relation data file to reach durable storage.
**IO:DataFileRead**
A backend process tried to find a page in the shared buffers, didn't find it, and so read it from storage. For more information, see [IO:DataFileRead](apg-waits.iodatafileread.md).
**IO:DataFileTruncate**
A process is waiting for a relation data file to be truncated.
**IO:DataFileWrite**
A process is waiting for a write to a relation data file.
**IO:DSMFillZeroWrite**
A process is waiting to write zero bytes to a dynamic shared memory backing file.
**IO:LockFileAddToDataDirRead**
A process is waiting for a read while adding a line to the data directory lock file.
**IO:LockFileAddToDataDirSync**
A process is waiting for data to reach durable storage while adding a line to the data directory lock file.
**IO:LockFileAddToDataDirWrite**
A process is waiting for a write while adding a line to the data directory lock file.
**IO:LockFileCreateRead**
A process is waiting to read while creating the data directory lock file.
**IO:LockFileCreateSync**
A process is waiting for data to reach durable storage while creating the data directory lock file.
**IO:LockFileCreateWrite**
A process is waiting for a write while creating the data directory lock file.
**IO:LockFileReCheckDataDirRead**
A process is waiting for a read during recheck of the data directory lock file.
**IO:LogicalRewriteCheckpointSync**
A process is waiting for logical rewrite mappings to reach durable storage during a checkpoint.
**IO:LogicalRewriteMappingSync**
A process is waiting for mapping data to reach durable storage during a logical rewrite.
**IO:LogicalRewriteMappingWrite**
A process is waiting for a write of mapping data during a logical rewrite.
**IO:LogicalRewriteSync**
A process is waiting for logical rewrite mappings to reach durable storage.
**IO:LogicalRewriteTruncate**
A process is waiting for the truncation of mapping data during a logical rewrite.
**IO:LogicalRewriteWrite**
A process is waiting for a write of logical rewrite mappings.
**IO:RelationMapRead**
A process is waiting for a read of the relation map file.
**IO:RelationMapSync**
A process is waiting for the relation map file to reach durable storage.
**IO:RelationMapWrite**
A process is waiting for a write to the relation map file.
**IO:ReorderBufferRead**
A process is waiting for a read during reorder buffer management.
**IO:ReorderBufferWrite**
A process is waiting for a write during reorder buffer management.
**IO:ReorderLogicalMappingRead**
A process is waiting for a read of a logical mapping during reorder buffer management.
**IO:ReplicationSlotRead**
A process is waiting for a read from a replication slot control file.
**IO:ReplicationSlotRestoreSync**
A process is waiting for a replication slot control file to reach durable storage while restoring it to memory.
**IO:ReplicationSlotSync**
A process is waiting for a replication slot control file to reach durable storage.
**IO:ReplicationSlotWrite**
A process is waiting for a write to a replication slot control file.
**IO:SLRUFlushSync**
A process is waiting for simple least-recently used (SLRU) data to reach durable storage during a checkpoint or database shutdown.
**IO:SLRURead**
A process is waiting for a read of a simple least-recently used (SLRU) page.
**IO:SLRUSync**
A process is waiting for simple least-recently used (SLRU) data to reach durable storage following a page write.
**IO:SLRUWrite**
A process is waiting for a write of a simple least-recently used (SLRU) page.
**IO:SnapbuildRead**
A process is waiting for a read of a serialized historical catalog snapshot.
**IO:SnapbuildSync**
A process is waiting for a serialized historical catalog snapshot to reach durable storage.
**IO:SnapbuildWrite**
A process is waiting for a write of a serialized historical catalog snapshot.
**IO:TimelineHistoryFileSync**
A process is waiting for a timeline history file received through streaming replication to reach durable storage.
**IO:TimelineHistoryFileWrite**
A process is waiting for a write of a timeline history file received through streaming replication.
**IO:TimelineHistoryRead**
A process is waiting for a read of a timeline history file.
**IO:TimelineHistorySync**
A process is waiting for a newly created timeline history file to reach durable storage.
**IO:TimelineHistoryWrite**
A process is waiting for a write of a newly created timeline history file.
**IO:TwophaseFileRead**
A process is waiting for a read of a two phase state file.
**IO:TwophaseFileSync**
A process is waiting for a two phase state file to reach durable storage.
**IO:TwophaseFileWrite**
A process is waiting for a write of a two phase state file.
**IO:WALBootstrapSync**
A process is waiting for the write-ahead log (WAL) to reach durable storage during bootstrapping.
**IO:WALBootstrapWrite**
A process is waiting for a write of a write-ahead log (WAL) page during bootstrapping.
**IO:WALCopyRead**
A process is waiting for a read when creating a new write-ahead log (WAL) segment by copying an existing one.
**IO:WALCopySync**
A process is waiting for a new write-ahead log (WAL) segment created by copying an existing one to reach durable storage.
**IO:WALCopyWrite**
A process is waiting for a write when creating a new write-ahead log (WAL) segment by copying an existing one.
**IO:WALInitSync**
A process is waiting for a newly initialized write-ahead log (WAL) file to reach durable storage.
**IO:WALInitWrite**
A process is waiting for a write while initializing a new write-ahead log (WAL) file.
**IO:WALRead**
A process is waiting for a read from a write-ahead log (WAL) file.
**IO:WALSenderTimelineHistoryRead**
A process is waiting for a read from a timeline history file during a WAL sender timeline command.
**IO:WALSync**
A process is waiting for a write-ahead log (WAL) file to reach durable storage.
**IO:WALSyncMethodAssign**
A process is waiting for data to reach durable storage while assigning a new write-ahead log (WAL) sync method.
**IO:WALWrite**
A process is waiting for a write to a write-ahead log (WAL) file.
**IO:XactSync**
A backend process is waiting for the Aurora storage subsystem to acknowledge the commit of a regular transaction, or the commit or rollback of a prepared transaction. For more information, see [IO:XactSync](apg-waits.xactsync.md).
**IPC:AuroraLogicalSchemaUpdate**
Two backend processes are attempting to insert the same entry into the schema cache. One process will continue while the other waits for it to complete.
**IPC:AuroraOptimizedReadsCacheWriteStop**
A process is waiting for the background writer to stop writing into Optimized Reads tiered cache.
**IPC:BackupWaitWalArchive**
A process is waiting for write-ahead log (WAL) files required for a backup to be successfully archived.
**IPC:BgWorkerShutdown**
A process is waiting for a background worker to shut down.
**IPC:BgWorkerStartup**
A process is waiting for a background worker to start.
**IPC:BtreePage**
A process is waiting for the page number needed to continue a parallel B-tree scan to become available.
**IPC:CheckpointDone**
A process is waiting for a checkpoint to complete.
**IPC:CheckpointStart**
A process is waiting for a checkpoint to start.
**IPC:ClogGroupUpdate**
A process is waiting for the group leader to update the transaction status at a transaction's end.
**IPC:DamRecordTxAck**
A backend process has generated a database activity streams event and is waiting for the event to become durable. For more information, see [IPC:DamRecordTxAck](apg-waits.ipcdamrecordtxac.md).
**IPC:ExecuteGather**
A process is waiting for activity from a child process while executing a Gather plan node.
**IPC:Hash/Batch/Allocating**
A process is waiting for an elected parallel hash participant to allocate a hash table.
**IPC:Hash/Batch/Electing**
A process is electing a parallel hash participant to allocate a hash table.
**IPC:Hash/Batch/Loading**
A process is waiting for other parallel hash participants to finish loading a hash table.
**IPC:Hash/Build/Allocating**
A process is waiting for an elected parallel hash participant to allocate the initial hash table.
**IPC:Hash/Build/Electing**
A process is electing a parallel hash participant to allocate the initial hash table.
**IPC:Hash/Build/HashingInner**
A process is waiting for other parallel hash participants to finish hashing the inner relation.
**IPC:Hash/Build/HashingOuter**
A process is waiting for other parallel hash participants to finish partitioning the outer relation.
**IPC:Hash/GrowBatches/Allocating**
A process is waiting for an elected parallel hash participant to allocate more batches.
**IPC:Hash/GrowBatches/Deciding**
A process is electing a parallel hash participant to decide on future batch growth.
**IPC:Hash/GrowBatches/Electing**
A process is electing a parallel hash participant to allocate more batches.
**IPC:Hash/GrowBatches/Finishing**
A process is waiting for an elected parallel hash participant to decide on future batch growth.
**IPC:Hash/GrowBatches/Repartitioning**
A process is waiting for other parallel hash participants to finishing repartitioning.
**IPC:Hash/GrowBuckets/Allocating**
A process is waiting for an elected parallel hash participant to finish allocating more buckets.
**IPC:Hash/GrowBuckets/Electing**
A process is electing a parallel hash participant to allocate more buckets.
**IPC:Hash/GrowBuckets/Reinserting**
A process is waiting for other parallel hash participants to finish inserting tuples into new buckets.
**IPC:HashBatchAllocate**
A process is waiting for an elected parallel hash participant to allocate a hash table.
**IPC:HashBatchElect**
A process is waiting to elect a parallel hash participant to allocate a hash table.
**IPC:HashBatchLoad**
A process is waiting for other parallel hash participants to finish loading a hash table.
**IPC:HashBuildAllocate**
A process is waiting for an elected parallel hash participant to allocate the initial hash table.
**IPC:HashBuildElect**
A process is waiting to elect a parallel hash participant to allocate the initial hash table.
**IPC:HashBuildHashInner**
A process is waiting for other parallel hash participants to finish hashing the inner relation.
**IPC:'HashBuildHashOuter**
A process is waiting for other parallel hash participants to finish partitioning the outer relation.
**IPC:HashGrowBatchesAllocate**
A process is waiting for an elected parallel hash participant to allocate more batches.
**IPC:'HashGrowBatchesDecide**
A process is waiting to elect a parallel hash participant to decide on future batch growth.
**IPC:HashGrowBatchesElect**
A process is waiting to elect a parallel hash participant to allocate more batches.
**IPC:HashGrowBatchesFinish**
A process is waiting for an elected parallel hash participant to decide on future batch growth.
**IPC:HashGrowBatchesRepartition**
A process is waiting for other parallel hash participants to finish repartitioning.
**IPC:HashGrowBucketsAllocate**
A process is waiting for an elected parallel hash participant to finish allocating more buckets.
**IPC:HashGrowBucketsElect**
A process is waiting to elect a parallel hash participant to allocate more buckets.
**IPC:HashGrowBucketsReinsert**
A process is waiting for other parallel hash participants to finish inserting tuples into new buckets.
**IPC:LogicalSyncData**
A process is waiting for a logical replication remote server to send data for initial table synchronization.
**IPC:LogicalSyncStateChange**
A process is waiting for a logical replication remote server to change state.
**IPC:MessageQueueInternal**
A process is waiting for another process to be attached to a shared message queue.
**IPC:MessageQueuePutMessage**
A process is waiting to write a protocol message to a shared message queue.
**IPC:MessageQueueReceive**
A process is waiting to receive bytes from a shared message queue.
**IPC:MessageQueueSend**
A process is waiting to send bytes to a shared message queue.
**IPC:ParallelBitmapScan**
A process is waiting for a parallel bitmap scan to become initialized.
**IPC:ParallelCreateIndexScan**
A process is waiting for parallel CREATE INDEX workers to finish a heap scan.
**IPC:ParallelFinish**
A process is waiting for parallel workers to finish computing.
**IPC:ProcArrayGroupUpdate**
A process is waiting for the group leader to clear the transaction ID at transaction end.
**IPC:ProcSignalBarrier**
A process is waiting for a barrier event to be processed by all backends.
**IPC:Promote**
A process is waiting for standby promotion.
**IPC:RecoveryConflictSnapshot**
A process is waiting for recovery conflict resolution for a vacuum cleanup.
**IPC:RecoveryConflictTablespace**
A process is waiting for recovery conflict resolution for dropping a tablespace.
**IPC:RecoveryPause**
A process is waiting for recovery to be resumed.
**IPC:ReplicationOriginDrop**
A process is waiting for a replication origin to become inactive so it can be dropped.
**IPC:ReplicationSlotDrop**
A process is waiting for a replication slot to become inactive so it can be dropped.
**IPC:SafeSnapshot**
A process is waiting to obtain a valid snapshot for a READ ONLY DEFERRABLE transaction.
**IPC:SyncRep**
A process is waiting for confirmation from a remote server during synchronous replication.
**IPC:XactGroupUpdate**
A process is waiting for the group leader to update the transaction status at transaction end.
**Lock:advisory**
A backend process requested an advisory lock and is waiting for it. For more information, see [Lock:advisory](apg-waits.lockadvisory.md).
**Lock:extend**
A backend process is waiting for a lock to be released so that it can extend a relation. This lock is needed because only one backend process can extend a relation at a time. For more information, see [Lock:extend](apg-waits.lockextend.md).
**Lock:frozenid**
A process is waiting to update `pg_database.datfrozenxid` and `pg_database.datminmxid`.
**Lock:object**
A process is waiting to get a lock on a nonrelation database object.
**Lock:page**
A process is waiting to get a lock on a page of a relation.
**Lock:Relation**
A backend process is waiting to acquire a lock on a relation that is locked by another transaction. For more information, see [Lock:Relation](apg-waits.lockrelation.md).
**Lock:spectoken**
A process is waiting to get a speculative insertion lock.
**Lock:speculative token**
A process is waiting to acquire a speculative insertion lock.
**Lock:transactionid**
A transaction is waiting for a row-level lock. For more information, see [Lock:transactionid](apg-waits.locktransactionid.md).
**Lock:tuple**
A backend process is waiting to acquire a lock on a tuple while another backend process holds a conflicting lock on the same tuple. For more information, see [Lock:tuple](apg-waits.locktuple.md).
**Lock:userlock**
A process is waiting to get a user lock.
**Lock:virtualxid**
A process is waiting to get a virtual transaction ID lock.
**LWLock:AddinShmemInit**
A process is waiting to manage an extension's space allocation in shared memory.
**LWLock:AddinShmemInitLock**
A process is waiting to manage space allocation in shared memory.
**LWLock:async**
A process is waiting for I/O on an async (notify) buffer.
**LWLock:AsyncCtlLock**
A process is waiting to read or update a shared notification state.
**LWLock:AsyncQueueLock**
A process is waiting to read or update notification messages.
**LWLock:AuroraOptimizedReadsCacheMapping**
A process is waiting to associate a data block with a page in the Optimized Reads tiered cache.
**LWLock:AutoFile**
A process is waiting to update the `postgresql.auto.conf` file.
**LWLock:AutoFileLock**
A process is waiting to update the `postgresql.auto.conf` file.
**LWLock:Autovacuum**
A process is waiting to read or update the current state of autovacuum workers.
**LWLock:AutovacuumLock**
An autovacuum worker or launcher is waiting to update or read the current state of autovacuum workers.
**LWLock:AutovacuumSchedule**
A process is waiting to ensure that a table selected for autovacuum still needs vacuuming.
**LWLock:AutovacuumScheduleLock**
A process is waiting to ensure that the table it has selected for a vacuum still needs vacuuming.
**LWLock:BackendRandomLock**
A process is waiting to generate a random number.
**LWLock:BackgroundWorker**
A process is waiting to read or update background worker state.
**LWLock:BackgroundWorkerLock**
A process is waiting to read or update the background worker state.
**LWLock:BtreeVacuum**
A process is waiting to read or update vacuum-related information for a B-tree index.
**LWLock:BtreeVacuumLock**
A process is waiting to read or update vacuum-related information for a B-tree index.
**LWLock:buffer\$1content**
A backend process is waiting to acquire a lightweight lock on the contents of a shared memory buffer. For more information, see [LWLock:buffer\$1content (BufferContent)](apg-waits.lockbuffercontent.md).
**LWLock:buffer\$1mapping**
A backend process is waiting to associate a data block with a buffer in the shared buffer pool. For more information, see [LWLock:buffer\$1mapping](apg-waits.lwl-buffer-mapping.md).
**LWLock:BufferIO**
A backend process wants to read a page into shared memory. The process is waiting for other processes to finish their I/O for the page. For more information, see [LWLock:BufferIO (IPC:BufferIO)](apg-waits.lwlockbufferio.md).
**LWLock:Checkpoint**
A process is waiting to begin a checkpoint.
**LWLock:CheckpointLock**
A process is waiting to perform checkpoint.
**LWLock:CheckpointerComm**
A process is waiting to manage `fsync` requests.
**LWLock:CheckpointerCommLock**
A process is waiting to manage `fsync` requests.
**LWLock:clog**
A process is waiting for I/O on a clog (transaction status) buffer.
**LWLock:CLogControlLock**
A process is waiting to read or update transaction status.
**LWLock:CLogTruncationLock**
A process is waiting to run `txid_status` or update the oldest transaction ID available to it.
**LWLock:commit\$1timestamp**
A process is waiting for I/O on a commit timestamp buffer.
**LWLock:CommitTs**
A process is waiting to read or update the last value set for a transaction commit timestamp.
**LWLock:CommitTsBuffer**
A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a commit timestamp.
**LWLock:CommitTsControlLock**
A process is waiting to read or update transaction commit timestamps.
**LWLock:CommitTsLock**
A process is waiting to read or update the last value set for the transaction timestamp.
**LWLock:CommitTsSLRU**
A process is waiting to access the simple least-recently used (SLRU) cache for a commit timestamp.
**LWLock:ControlFile**
A process is waiting to read or update the `pg_control` file or create a new write-ahead log (WAL) file.
**LWLock:ControlFileLock**
A process is waiting to read or update the control file or creation of a new write-ahead log (WAL) file.
**LWLock:DynamicSharedMemoryControl**
A process is waiting to read or update dynamic shared memory allocation information.
**LWLock:DynamicSharedMemoryControlLock**
A process is waiting to read or update the dynamic shared memory state.
**LWLock:lock\$1manager**
A backend process is waiting to add or examine locks for backend processes. Or it's waiting to join or exit a locking group that is used by parallel query. For more information, see [LWLock:lock\$1manager](apg-waits.lw-lock-manager.md).
**LWLock:LockFastPath**
A process is waiting to read or update a process's fast-path lock information.
**LWLock:LogicalRepWorker**
A process is waiting to read or update the state of logical replication workers.
**LWLock:LogicalRepWorkerLock**
A process is waiting for an action on a logical replication worker to finish.
**LWLock:LogicalSchemaCache**
A process modified the schema cache.
**LWLock:multixact\$1member**
A process is waiting for I/O on a multixact\$1member buffer.
**LWLock:multixact\$1offset**
A process is waiting for I/O on a multixact offset buffer.
**LWLock:MultiXactGen**
A process is waiting to read or update shared multixact state.
**LWLock:MultiXactGenLock**
A process is waiting to read or update a shared multixact state.
**LWLock:MultiXactMemberBuffer**
A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a multixact member. For more information, see [LWLock:MultiXact](apg-waits.lwlockmultixact.md).
**LWLock:MultiXactMemberControlLock**
A process is waiting to read or update multixact member mappings.
**LWLock:MultiXactMemberSLRU**
A process is waiting to access the simple least-recently used (SLRU) cache for a multixact member. For more information, see [LWLock:MultiXact](apg-waits.lwlockmultixact.md).
**LWLock:MultiXactOffsetBuffer**
A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a multixact offset. For more information, see [LWLock:MultiXact](apg-waits.lwlockmultixact.md).
**LWLock:MultiXactOffsetControlLock**
A process is waiting to read or update multixact offset mappings.
**LWLock:MultiXactOffsetSLRU**
A process is waiting to access the simple least-recently used (SLRU) cache for a multixact offset. For more information, see [LWLock:MultiXact](apg-waits.lwlockmultixact.md).
**LWLock:MultiXactTruncation**
A process is waiting to read or truncate multixact information.
**LWLock:MultiXactTruncationLock**
A process is waiting to read or truncate multixact information.
**LWLock:NotifyBuffer**
A process is waiting for I/O on the simple least-recently used (SLRU) buffer for a NOTIFY message.
**LWLock:NotifyQueue**
A process is waiting to read or update NOTIFY messages.
**LWLock:NotifyQueueTail**
A process is waiting to update a limit on NOTIFY message storage.
**LWLock:NotifyQueueTailLock**
A process is waiting to update limit on notification message storage.
**LWLock:NotifySLRU**
A process is waiting to access the simple least-recently used (SLRU) cache for a NOTIFY message.
**LWLock:OidGen**
A process is waiting to allocate a new object ID (OID).
**LWLock:OidGenLock**
A process is waiting to allocate or assign an object ID (OID).
**LWLock:oldserxid**
A process is waiting for I/O on an oldserxid buffer.
**LWLock:OldSerXidLock**
A process is waiting to read or record conflicting serializable transactions.
**LWLock:OldSnapshotTimeMap**
A process is waiting to read or update old snapshot control information.
**LWLock:OldSnapshotTimeMapLock**
A process is waiting to read or update old snapshot control information.
**LWLock:parallel\$1append**
A process is waiting to choose the next subplan during parallel append plan execution.
**LWLock:parallel\$1hash\$1join**
A process is waiting to allocate or exchange a chunk of memory or update counters during a parallel hash plan execution.
**LWLock:parallel\$1query\$1dsa**
A process is waiting for a lock on dynamic shared memory allocation for a parallel query.
**LWLock:ParallelAppend**
A process is waiting to choose the next subplan during parallel append plan execution.
**LWLock:ParallelHashJoin**
A process is waiting to synchronize workers during plan execution for a parallel hash join.
**Lwlock:ParallelQueryDSA**
A process is waiting for dynamic shared memory allocation for a parallel query.
**Lwlock:PerSessionDSA**
A process is waiting for dynamic shared memory allocation for a parallel query.
**Lwlock:PerSessionRecordType**
A process is waiting to access a parallel query's information about composite types.
**Lwlock:PerSessionRecordTypmod**
A process is waiting to access a parallel query's information about type modifiers that identify anonymous record types.
**Lwlock:PerXactPredicateList**
A process is waiting to access the list of predicate locks held by the current serializable transaction during a parallel query.
**Lwlock:predicate\$1lock\$1manager**
A process is waiting to add or examine predicate lock information.
**Lwlock:PredicateLockManager**
A process is waiting to access predicate lock information used by serializable transactions.
**Lwlock:proc**
A process is waiting to read or update the fast-path lock information.
**LWLock:ProcArray**
A process is waiting to access the shared per-process data structures (typically, to get a snapshot or report a session's transaction ID).
**LWLock:ProcArrayLock**
A process is waiting to get a snapshot or clearing a transaction Id at a transaction's end.
**LWLock:RelationMapping**
A process is waiting to read or update a `pg_filenode.map` file (used to track the file-node assignments of certain system catalogs).
**LWLock:RelationMappingLock**
A process is waiting to update the relation map file used to store catalog-to-file-node mapping.
**LWLock:RelCacheInit**
A process is waiting to read or update a `pg_internal.init` file (a relation cache initialization file).
**LWLock:RelCacheInitLock**
A process is waiting to read or write a relation cache initialization file.
**LWLock:replication\$1origin**
A process is waiting to read or update the replication progress.
**LWLock:replication\$1slot\$1io**
A process is waiting for I/O on a replication slot.
**LWLock:ReplicationOrigin**
A process is waiting to create, drop, or use a replication origin.
**LWLock:ReplicationOriginLock**
A process is waiting to set up, drop, or use a replication origin.
**LWLock:ReplicationOriginState**
A process is waiting to read or update the progress of one replication origin.
**LWLock:ReplicationSlotAllocation**
A process is waiting to allocate or free a replication slot.
**LWLock:ReplicationSlotAllocationLock**
A process is waiting to allocate or free a replication slot.
**LWLock:ReplicationSlotControl**
A process is waiting to read or update a replication slot state.
**LWLock:ReplicationSlotControlLock**
A process is waiting to read or update the replication slot state.
**LWLock:ReplicationSlotIO**
A process is waiting for I/O on a replication slot.
**LWLock:SerialBuffer**
A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a serializable transaction conflict.
**LWLock:SerializableFinishedList**
A process is waiting to access the list of finished serializable transactions.
**LWLock:SerializableFinishedListLock**
A process is waiting to access the list of finished serializable transactions.
**LWLock:SerializablePredicateList**
A process is waiting to access the list of predicate locks held by serializable transactions.
**LWLock:SerializablePredicateLockListLock**
A process is waiting to perform an operation on a list of locks held by serializable transactions.
**LWLock:SerializableXactHash**
A process is waiting to read or update information about serializable transactions.
**LWLock:SerializableXactHashLock**
A process is waiting to retrieve or store information about serializable transactions.
**LWLock:SerialSLRU**
A process is waiting to access the simple least-recently used (SLRU) cache for a serializable transaction conflict.
**LWLock:SharedTidBitmap**
A process is waiting to access a shared tuple identifier (TID) bitmap during a parallel bitmap index scan.
**LWLock:SharedTupleStore**
A process is waiting to access a shared tuple store during a parallel query.
**LWLock:ShmemIndex**
A process is waiting to find or allocate space in shared memory.
**LWLock:ShmemIndexLock**
A process is waiting to find or allocate space in shared memory.
**LWLock:SInvalRead**
A process is waiting to retrieve messages from the shared catalog invalidation queue.
**LWLock:SInvalReadLock**
A process is waiting to retrieve or remove messages from a shared invalidation queue.
**LWLock:SInvalWrite**
A process is waiting to add a message to the shared catalog invalidation queue.
**LWLock:SInvalWriteLock**
A process is waiting to add a message in a shared invalidation queue.
**LWLock:SyncRep**
A process is waiting to read or update information about the state of synchronous replication.
**LWLock:SyncRepLock**
A process is waiting to read or update information about synchronous replicas.
**LWLock:SyncScan**
A process is waiting to select the starting location of a synchronized table scan.
**LWLock:SyncScanLock**
A process is waiting to get the start location of a scan on a table for synchronized scans.
**LWLock:TablespaceCreate**
A process is waiting to create or drop a tablespace.
**LWLock:TablespaceCreateLock**
A process is waiting to create or drop the tablespace.
**LWLock:tbm**
A process is waiting for a shared iterator lock on a tree bitmap (TBM).
**LWLock:TwoPhaseState**
A process is waiting to read or update the state of prepared transactions.
**LWLock:TwoPhaseStateLock**
A process is waiting to read or update the state of prepared transactions.
**LWLock:wal\$1insert**
A process is waiting to insert the write-ahead log (WAL) into a memory buffer.
**LWLock:WALBufMapping**
A process is waiting to replace a page in write-ahead log (WAL) buffers.
**LWLock:WALBufMappingLock**
A process is waiting to replace a page in write-ahead log (WAL) buffers.
**LWLock:WALInsert**
A process is waiting to insert write-ahead log (WAL) data into a memory buffer.
**LWLock:WALWrite**
A process is waiting for write-ahead log (WAL) buffers to be written to disk.
**LWLock:WALWriteLock**
A process is waiting for write-ahead log (WAL) buffers to be written to disk.
**LWLock:WrapLimitsVacuum**
A process is waiting to update limits on transaction ID and multixact consumption.
**LWLock:WrapLimitsVacuumLock**
A process is waiting to update limits on transaction ID and multixact consumption.
**LWLock:XactBuffer**
A process is waiting for I/O on a simple least-recently used (SLRU) buffer for a transaction status.
**LWLock:XactSLRU**
A process is waiting to access the simple least-recently used (SLRU) cache for a transaction status.
**LWLock:XactTruncation**
A process is waiting to run pg\$1xact\$1status or update the oldest transaction ID available to it.
**LWLock:XidGen**
A process is waiting to allocate a new transaction ID.
**LWLock:XidGenLock**
A process is waiting to allocate or assign a transaction ID.
**Timeout:BaseBackupThrottle**
A process is waiting during base backup when throttling activity.
**Timeout:PgSleep**
A backend process has called the pg\$1sleep function and is waiting for the sleep timeout to expire. For more information, see [Timeout:PgSleep](apg-waits.timeoutpgsleep.md).
**Timeout:RecoveryApplyDelay**
A process is waiting to apply write-ahead log (WAL) during recovery because of a delay setting.
**Timeout:RecoveryRetrieveRetryInterval**
A process is waiting during recovery when write-ahead log (WAL) data is not available from any source (pg\$1wal, archive, or stream).
**Timeout:VacuumDelay**
A process is waiting in a cost-based vacuum delay point.
For a complete list of PostgreSQL wait events, see [The Statistics Collector > Wait Event tables](https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE) in the PostgreSQL documentation.
# Database engine updates for Amazon Aurora PostgreSQL
Following, you can find information about Amazon Aurora PostgreSQL engine version releases and updates. You can also find information about how to upgrade your Aurora PostgreSQL engine. For more information about Aurora releases in general, see [Amazon Aurora versions](Aurora.VersionPolicy.md).
**Tip**
You can minimize the downtime required for a DB cluster upgrade by using a blue/green deployment. For more information, see [Using Amazon Aurora Blue/Green Deployments for database updates](blue-green-deployments.md).
**Topics**
+ [Identifying versions of Amazon Aurora PostgreSQL](#AuroraPostgreSQL.Updates.Versions)
+ [Amazon Aurora PostgreSQL releases and engine versions](AuroraPostgreSQL.Updates.20180305.md)
+ [Extension versions for Amazon Aurora PostgreSQL](AuroraPostgreSQL.Extensions.md)
+ [Upgrading Amazon Aurora PostgreSQL DB clusters](USER_UpgradeDBInstance.PostgreSQL.md)
+ [Using an Aurora PostgreSQL long-term support (LTS) release](AuroraPostgreSQL.Updates.LTS.md)
## Identifying versions of Amazon Aurora PostgreSQL
Amazon Aurora includes certain features that are general to Aurora and available to all Aurora DB clusters. Aurora includes other features that are specific to a particular database engine that Aurora supports. These features are available only to those Aurora DB clusters that use that database engine, such as Aurora PostgreSQL.
An Aurora database release typically has two version numbers, the database engine version number and the Aurora version number. If an Aurora PostgreSQL release has an Aurora version number, it's included after the engine version number in the [Amazon Aurora PostgreSQL releases and engine versions](AuroraPostgreSQL.Updates.20180305.md) listing.
**Topics**
+ [Aurora version number](#AuroraPostgreSQL.Updates.Versions.AuroraNumber)
+ [PostgreSQL engine version numbers](#AuroraPostgreSQL.Updates.Versions.EngineNumber)
### Aurora version number
Aurora version numbers use the *major*.*minor*.*patch* naming scheme. An Aurora patch version includes important bug fixes added to a minor version after its release. To learn more about Amazon Aurora major, minor, and patch releases, see [Amazon Aurora major versions](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersions), [Amazon Aurora minor versions](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MinorVersions), and [Amazon Aurora patch versions](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.PatchVersions).
You can find out the Aurora version number of your Aurora PostgreSQL DB instance with the following SQL query:
```
postgres=> SELECT aurora_version();
```
Starting with the release of PostgreSQL versions 13.3, 12.8, 11.13, 10.18, and for all other later versions, Aurora version numbers align more closely to the PostgreSQL engine version. For example, querying an Aurora PostgreSQL 13.3 DB cluster returns the following:
```
aurora_version
----------------
13.3.1
(1 row)
```
Prior releases, such as Aurora PostgreSQL 10.14 DB cluster, return version numbers similar to the following:
```
aurora_version
----------------
2.7.3
(1 row)
```
### PostgreSQL engine version numbers
Starting with PostgreSQL 10, PostgreSQL database engine versions use a *major*.*minor* numbering scheme for all releases. Some examples include PostgreSQL 10.18, PostgreSQL 12.7, and PostgreSQL 13.3.
Releases prior to PostgreSQL 10 used a *major*.*major*.*minor* numbering scheme in which the first two digits make up the major version number and a third digit denotes a minor version. For example, PostgreSQL 9.6 was a major version, with minor versions 9.6.21 or 9.6.22 indicated by the third digit.
**Note**
The PostgreSQL engine version 9.6 is no longer supported. To upgrade, see [Upgrading Amazon Aurora PostgreSQL DB clusters](USER_UpgradeDBInstance.PostgreSQL.md). For version policies and release timelines, see [How long Amazon Aurora major versions remain available](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersionLifetime).
You can find out the PostgreSQL database engine version number with the following SQL query:
```
postgres=> SELECT version();
```
For an Aurora PostgreSQL 13.3 DB cluster, the results are as follows:
```
version
-------------------------------------------------------------------------------------------------
PostgreSQL 13.3 on x86_64-pc-linux-gnu, compiled by x86_64-pc-linux-gnu-gcc (GCC) 7.4.0, 64-bit
(1 row)
```
# Amazon Aurora PostgreSQL releases and engine versions
Amazon Aurora PostgreSQL-Compatible Edition releases are updated regularly. Updates are applied to Aurora PostgreSQL DB clusters during system maintenance windows. When updates are applied depends on the type of update, the AWS Region, and maintenance window setting for the DB cluster. Many of the listed releases include both a PostgreSQL version number and an Amazon Aurora version number. However, starting with the release of PostgreSQL versions 13.3, 12.8, 11.13, 10.18, and for all other later versions, Aurora version numbers aren't used. To identify the version numbers of your Aurora PostgreSQL database, see [Identifying versions of Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions).
For information about extensions and modules, see [Extension versions for Amazon Aurora PostgreSQL](AuroraPostgreSQL.Extensions.md).
**Note**
For information about Amazon Aurora version policies and release timelines, see [How long Amazon Aurora major versions remain available](Aurora.VersionPolicy.Versioning.md#Aurora.VersionPolicy.MajorVersionLifetime).
For information about support for Amazon Aurora see [Amazon RDS FAQs](https://aws.amazon.com/rds/faqs/).
To determine which Aurora PostgreSQL DB engine versions are available in an AWS Region, use the [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI command. For example:
```
aws rds describe-db-engine-versions --engine aurora-postgresql --query '*[].[EngineVersion]' --output text --region aws-region
```
For a list of AWS Regions, see [Aurora PostgreSQL Region availability](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability.PostgreSQL).
For details about the PostgreSQL versions that are available on Aurora PostgreSQL, see the [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html).
# Extension versions for Amazon Aurora PostgreSQL
You can install and configure various PostgreSQL extensions for use with Aurora PostgreSQL DB clusters. For example, you can use the PostgreSQL `pg_partman` extension to automate the creation and maintenance of table partitions. To learn more about this and other extensions available for Aurora PostgreSQL, see [Working with extensions and foreign data wrappers](Appendix.PostgreSQL.CommonDBATasks.md).
For details about the PostgreSQL extensions that are supported on Aurora PostgreSQL, see [Extension versions for Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Extensions.html) in *Release Notes for Aurora PostgreSQL*.
# Upgrading Amazon Aurora PostgreSQL DB clusters
Amazon Aurora makes new versions of the PostgreSQL database engine available in AWS Regions only after extensive testing. You can upgrade your Aurora PostgreSQL DB clusters to the new version when it's available in your Region.
Depending on the version of Aurora PostgreSQL that your DB cluster is currently running, an upgrade to the new release is either a minor upgrade or a major upgrade. For example, upgrading an Aurora PostgreSQL 11.15 DB cluster to Aurora PostgreSQL 13.6 is a *major version upgrade*. Upgrading an Aurora PostgreSQL 13.3 DB cluster to Aurora PostgreSQL 13.7 is a *minor version upgrade*. In the following topics, you can find information about how to perform both types of upgrades.
**Contents**
+ [Overview of the Aurora PostgreSQL upgrade processes](#USER_UpgradeDBInstance.PostgreSQL.Overview)
+ [Getting a list of available versions in your AWS Region](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md)
+ [Performing a major version upgrade](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md)
+ [Testing an upgrade of your production DB cluster to a new major version](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary)
+ [Post-upgrade recommendations](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.postupgrade)
+ [Upgrading the Aurora PostgreSQL engine to a new major version](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.Upgrading.Manual)
+ [Major upgrades for global databases](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.GlobalDB)
+ [Performing a minor version upgrade](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md)
+ [Before performing a minor version upgrade](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [How to perform minor version upgrades and apply patches](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor)
+ [Minor release upgrades and zero-downtime patching](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp)
+ [Limitations of zero-downtime patching](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations)
+ [Upgrading the Aurora PostgreSQL engine to a new minor version](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.MinorUpgrade)
+ [Upgrading PostgreSQL extensions](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)
+ [Alternative blue/green upgrade technique](#USER_UpgradeDBInstance.Upgrading.BlueGreen)
## Overview of the Aurora PostgreSQL upgrade processes
The differences between major and minor version upgrades are as follows:
**Minor version upgrades and patches**
Minor version upgrades and patches include only those changes that are backward-compatible with existing applications. Minor version upgrades and patches become available to you only after Aurora PostgreSQL tests and approves them.
Aurora can apply minor version upgrades for you automatically. When you create a new Aurora PostgreSQL DB cluster, the **Enable minor version upgrade** option is enabled by default. Unless you manually turn off this option, Aurora periodically applies automatic minor version upgrades during your scheduled maintenance window. For more information about the automatic minor version upgrade (AmVU) option and how to modify your Aurora DB cluster to use it, see [Automatic minor version upgrades for Aurora DB clusters](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
If automatic minor version upgrade isn't enabled for your Aurora PostgreSQL DB cluster, your Aurora PostgreSQL isn't automatically upgraded to a new minor version. Instead, when a new minor version is released in your AWS Region and your Aurora PostgreSQL DB cluster is running an older minor version, Aurora prompts you to upgrade. It does so by adding a recommendation to the maintenance tasks for your cluster.
Patches aren't considered an upgrade, and they aren't applied automatically. Aurora PostgreSQL prompts you to apply any patches by adding a recommendation to maintenance tasks for your Aurora PostgreSQL DB cluster. For more information, see [How to perform minor version upgrades and apply patches](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor).
Patches that resolve security or other critical issues are also added as maintenance tasks. However, these patches are required. Make sure to apply security patches to your Aurora PostgreSQL DB cluster when they become available in your pending maintenance tasks.
Auto minor version upgrades are performed to the default minor version. For more information, see [Automatic minor version upgrades for Aurora DB clusters](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
For clusters with Automatic Minor Version Upgrade enabled, if cluster availability is impacted by an issue that is fixed in a more recent patch, the patch will be applied during your maintenance window to resolve the issue with 2 weeks' advance notice.
The upgrade process involves the possibility of brief outages as each instance in the cluster is upgraded to the new version. However, after Aurora PostgreSQL versions 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3 and other higher releases of these minor versions and newer major versions, the upgrade process uses the zero-downtime patching (ZDP) feature. This feature minimizes outages, and in most cases completely eliminates them. For more information, see [Minor release upgrades and zero-downtime patching](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp). For more information on the supported features and limitations of ZDP, see [Limitations of zero-downtime patching](USER_UpgradeDBInstance.PostgreSQL.MinorUpgrade.md#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations).
**Major version upgrades**
Unlike for minor version upgrades and patches, Aurora PostgreSQL doesn't have an automatic major version upgrade option. New major PostgreSQL versions might contain database changes that aren't backward-compatible with existing applications. The new functionality can cause your existing applications to stop working correctly.
To prevent any issues, we strongly recommend that you follow the process outlined in [Testing an upgrade of your production DB cluster to a new major version](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) before upgrading the DB instances in your Aurora PostgreSQL DB clusters. First ensure that your applications can run on the new version by following that procedure. Then you can manually upgrade your Aurora PostgreSQL DB cluster to the new version.
The upgrade process involves the possibility of brief outage when all the instances in the cluster are upgraded to the new version. The preliminary planning process also takes time. We recommend that you always perform upgrade tasks during your cluster's maintenance window or when operations are minimal. For more information, see [Performing a major version upgrade](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md).
**Note**
Both minor version upgrades and major version upgrades might involve brief outages. For that reason, we recommend strongly that you perform or schedule upgrades during your maintenance window or during other periods of low utilization.
Aurora PostgreSQL DB clusters occasionally require operating system updates. These updates might include a newer version of glibc library. During such updates, we recommend you to follow the guidelines as described in [Collations supported in Aurora PostgreSQL ](PostgreSQL-Collations.md).
# Getting a list of available versions in your AWS Region
You can get a list of all engine versions available as upgrade targets for your Aurora PostgreSQL DB cluster by querying your AWS Region using the [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI command, as follows.
For Linux, macOS, or Unix:
```
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--engine-version version-number \
--query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
--output text
```
For Windows:
```
aws rds describe-db-engine-versions ^
--engine aurora-postgresql ^
--engine-version version-number ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output text
```
For example, to identify the valid upgrade targets for an Aurora PostgreSQL version 12.10 DB cluster, run the following AWS CLI command:
For Linux, macOS, or Unix:
```
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--engine-version 12.10 \
--query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
--output text
```
For Windows:
```
aws rds describe-db-engine-versions ^
--engine aurora-postgresql ^
--engine-version 12.10 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output text
```
In the following table, you can find both major and minor version upgrade targets for different Aurora PostgreSQL DB versions. To maintain compatibility, not all versions are offered as upgrade targets. Aurora PostgreSQL introduces new features and bug fixes with each quarterly minor version release. For information about Aurora PostgreSQL minor releases, see the [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html).
| Current source version | Upgrade targets |
| --- | --- |
| 17.9 | None |
| 17.7 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x) |
| 17.6 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) |
| 17.5 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x) |
| 17.4 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) |
| 16.13 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x) |
| 16.11 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x) |
| 16.10 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) |
| 16.9 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x) |
| 16.8 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) |
| 16.6 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) |
| 16.4 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) |
| 16.3 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x) |
| 16.2 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x) |
| 16.10 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x) |
| 15.17 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x) |
| 15.15 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x) |
| 15.14 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x) |
| 15.13 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x) |
| 15.12 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x) |
| 15.10 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x) |
| 15.8 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x) |
| 15.7 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x) |
| 15.6 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x) |
| 15.5 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x) |
| 15.4 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x) |
| 15.3 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x) |
| 15.2 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x) |
| 14.22 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x) |
| 14.20 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x) |
| 14.19 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x) |
| 14.18 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x) |
| 14.17 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x) |
| 14.15 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x) |
| 14.13 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x) |
| 14.12 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x) |
| 14.11 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x) |
| 14.10 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x) |
| 14.9 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x) |
| 14.8 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x) |
| 14.7 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x) |
| 14.6 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x) |
| 14.5 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x) |
| 14.4 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x), [14.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version145x) |
| 14.3 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x), [14.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version144x) |
| 13.23 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x) |
| 13.22 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x) |
| 13.21 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x) |
| 13.20 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x) |
| 13.18 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x) |
| 13.16 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x) |
| 13.15 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x) |
| 13.14 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x) |
| 13.13 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x) |
| 13.12 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x) |
| 13.11 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x) |
| 13.10 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x), [13.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1311x) |
| 13.9 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x), [13.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1311x), [13.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1310x) |
| 13.8 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x), [14.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version145x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x), [13.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1311x), [13.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1310x), [13.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version139x) |
| 13.7 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x), [14.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version145x), [14.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version144x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1315x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x), [13.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1311x), [13.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1310x), [13.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version139x), [13.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version138x) |
| 12.22 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x) |
| 12.9 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1322x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x), [13.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1311x), [13.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1310x), [13.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version139x), [13.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version138x), [13.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version137x) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1222x), [12.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1220x), [12.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1219x), [12.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1218x), [12.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1217x), [12.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1216x), [12.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1215x), [12.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1214x), [12.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1213x), [12.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1212x), [12.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1211x) |
| 11.21 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x) |
| 11.9 | [17.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version179x), [17.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version176x), [17.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version175x), [17.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version174x) [16.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1613x), [16.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1611x), [16.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1610x), [16.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version169x), [16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x), [16.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version166x), [16.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version164x), [16.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version163x), [16.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version162x), [16.1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version161x) [15.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1517x), [15.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1515x), [15.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1514x), [15.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1513x), [15.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1512x), [15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x), [15.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version158x), [15.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version157x), [15.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version156x), [15.5](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version155x), [15.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version154x), [15.3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version153x), [15.2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version152x) [14.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1422x), [14.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1420x), [14.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1419x), [14.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1418x), [14.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1417x), [14.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1415x), [14.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1413x), [14.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1412x), [14.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1411x), [14.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1410x), [14.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version149x), [14.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version148x), [14.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version147x), [14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version146x) [13.23](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1323x), [13.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1321x), [13.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1320x), [13.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1318x), [13.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1316x), [13.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1314x), [13.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1313x), [13.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1312x), [13.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1311x), [13.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1310x), [13.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version139x) [12.22](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1222x), [12.20](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1220x), [12.19](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1219x), [12.18](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1218x), [12.17](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1217x), [12.16](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1216x), [12.15](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1215x), [12.14](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1214x), [12.13](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1213x), [12.12](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1212x), [12.11](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1211x), [12.09](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1209x) [11.21](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1121x) |
For any version that you're considering, always check the availability of your cluster's DB instance class. For example, `db.r4` isn't supported for Aurora PostgreSQL 13. If your Aurora PostgreSQL DB cluster currently uses a db.r4 instance class, you need to modify it to use a supported DB instance class before you can upgrade to Aurora PostgreSQL 13. For more information about the available Aurora PostgreSQL DB instance classes, including which ones are Graviton2-based and which ones are Intel-based, see [Amazon AuroraDB instance classes](Concepts.DBInstanceClass.md).
# Performing a major version upgrade
Major version upgrades might contain database changes that are not backward-compatible with previous versions of the database. New functionality in a new version can cause your existing applications to stop working correctly. To avoid issues, Amazon Aurora doesn't apply major version upgrades automatically. Rather, we recommend that you carefully plan for a major version upgrade by following these steps:
1. Choose the major version that you want from the list of available targets from those listed for your version in the table. You can get a precise list of versions available in your AWS Region for your current version by using the AWS CLI. For details, see [Getting a list of available versions in your AWS Region](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md).
1. Verify that your applications work as expected on a trial deployment of the new version. For information about the complete process, see [Testing an upgrade of your production DB cluster to a new major version](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
1. After verifying that your applications work as expected on the trial deployment, you can upgrade your cluster. For details, see [Upgrading the Aurora PostgreSQL engine to a new major version](#USER_UpgradeDBInstance.Upgrading.Manual).
**Note**
You can perform a major version upgrade from Babelfish for Aurora PostgreSQL 13-based versions starting from 13.6 to Aurora PostgreSQL 14-based versions starting from 14.6. Babelfish for Aurora PostgreSQL 13.4 and 13.5 don't support major version upgrade.
You can get a list of engine versions available as major version upgrade targets for your Aurora PostgreSQL DB cluster by querying your AWS Region using the [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI command, as follows.
For Linux, macOS, or Unix:
```
aws rds describe-db-engine-versions \
--engine aurora-postgresql \
--engine-version version-number \
--query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
--output text
```
For Windows:
```
aws rds describe-db-engine-versions ^
--engine aurora-postgresql ^
--engine-version version-number ^
--query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
--output text
```
In some cases, the version that you want to upgrade to isn't a target for your current version. In such cases, use the information in the [versions table](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md#versions-table) to perform minor version upgrades until your cluster is at a version that has your chosen target in its row of targets.
## Testing an upgrade of your production DB cluster to a new major version
Each new major version includes enhancements to the query optimizer that are designed to improve performance. However, your workload might include queries that result in a worse performing plan in the new version. That's why we recommend that you test and review performance before upgrading in production. You can manage query plan stability across versions by using the Query Plan Management (QPM) extension, as detailed in [Ensuring plan stability after a major version upgrade](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade).
Before upgrading your production Aurora PostgreSQL DB clusters to a new major version, we strongly recommend that you test the upgrade to verify that all your applications work correctly:
1. Have a version-compatible parameter group ready.
If you are using a custom DB instance or DB cluster parameter group, you can choose from two options:
1. Specify the default DB instance, DB cluster parameter group, or both for the new DB engine version.
1. Create your own custom parameter group for the new DB engine version.
1. Check for invalid databases and drop any that exist.
The `datconnlimit` column in the `pg_database` catalog includes a value of `-2` to mark as invalid any databases that were interrupted during a `DROP DATABASE` operation. Use the following query to check whether invalid databases exist.
```
SELECT
datname
FROM
pg_database
WHERE
datconnlimit = - 2;
```
If the query returns database names, these databases are invalid. Use the `DROP DATABASE invalid_db_name` statement to drop invalid databases. You can use the following dynamic statement to drop all invalid databases.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
1. Check for unsupported usage:
+ Commit or roll back all open prepared transactions before attempting an upgrade. You can use the following query to verify that there are no open prepared transactions on your instance.
```
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
```
+ Remove all uses of the *reg\$1* data types before attempting an upgrade. Except for `regtype` and `regclass`, you can't upgrade the *reg\$1* data types. The pg\$1upgrade utility (used by Amazon Aurora to do the upgrade) can't persist this data type. To learn more about this utility, see [pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) in the PostgreSQL documentation.
To verify that there are no uses of unsupported *reg\$1* data types, use the following query for each database.
```
SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a
WHERE c.oid = a.attrelid
AND NOT a.attisdropped
AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype,
'pg_catalog.regprocedure'::pg_catalog.regtype,
'pg_catalog.regoper'::pg_catalog.regtype,
'pg_catalog.regoperator'::pg_catalog.regtype,
'pg_catalog.regconfig'::pg_catalog.regtype,
'pg_catalog.regdictionary'::pg_catalog.regtype)
AND c.relnamespace = n.oid
AND n.nspname NOT IN ('pg_catalog', 'information_schema');
```
+ If you are upgrading an Aurora PostgreSQL version 10.18 or higher DB cluster that has the `pgRouting` extension installed, drop the extension before upgrading to version 12.4 or higher.
If you are upgrading an Aurora PostgreSQL 10.x version that has the extension `pg_repack` version 1.4.3 installed, drop the extension before upgrading to any higher version.
1. Check for template1 and template0 databases.
For a successful upgrade, template 1 and template 0 databases must exist and should be listed as a template. To check on this, use the following command:
```
SELECT datname, datistemplate FROM pg_database;
datname | datistemplate
-----------+---------------
template0 | t
rdsadmin | f
template1 | t
postgres | f
```
In the command output, the `datistemplate` value for template1 and template0 databases should be `t`.
1. Drop logical replication slots.
The upgrade process can't proceed if the Aurora PostgreSQL DB cluster is using any logical replication slots. Logical replication slots are typically used for short-term data migration tasks, such as migrating data using AWS DMS or for replicating tables from the database to data lakes, BI tools, or other targets. Before upgrading, make sure that you know the purpose of any logical replication slots that exist, and confirm that it's okay to delete them. You can check for logical replication slots using the following query:
```
SELECT * FROM pg_replication_slots;
```
If logical replication slots are still being used, you shouldn't delete them, and you can't proceed with the upgrade. However, if the logical replication slots aren't needed, you can delete them using the following SQL:
```
SELECT pg_drop_replication_slot(slot_name);
```
Logical replication scenarios that use the `pglogical` extension also need to have slots dropped from the publisher node for a successful major version upgrade on that node. However, you can restart the replication process from the subscriber node after the upgrade. For more information, see [Reestablishing logical replication after a major upgrade](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md).
1. Perform a backup.
The upgrade process creates a DB cluster snapshot of your DB cluster during upgrading. If you also want to do a manual backup before the upgrade process, see [Creating a DB cluster snapshot](USER_CreateSnapshotCluster.md) for more information.
1. Upgrade certain extensions to the latest available version before performing the major version upgrade. The extensions to update include the following:
+ `pgRouting`
+ `postgis_raster`
+ `postgis_tiger_geocoder`
+ `postgis_topology`
+ `address_standardizer`
+ `address_standardizer_data_us`
Run the following command for each extension that's currently installed.
```
ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
```
For more information, see [Upgrading PostgreSQL extensions](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). To learn more about upgrading PostGIS, see [Step 6: Upgrade the PostGIS extension](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update).
1. If you're upgrading to version 11.x, drop the extensions that it doesn't support before performing the major version upgrade. The extensions to drop include:
+ `chkpass`
+ `tsearch2`
1. Drop `unknown` data types, depending on your target version.
PostgreSQL version 10 doesn't support the `unknown` data type. If a version 9.6 database uses the `unknown` data type, an upgrade to version 10 shows an error message such as the following.
```
Database instance is in a state that cannot be upgraded: PreUpgrade checks failed:
The instance could not be upgraded because the 'unknown' data type is used in user tables.
Please remove all usages of the 'unknown' data type and try again."
```
To find the `unknown` data type in your database so that you can remove such columns or change them to supported data types, use the following SQL code for each database.
```
SELECT n.nspname, c.relname, a.attname
FROM pg_catalog.pg_class c,
pg_catalog.pg_namespace n,
pg_catalog.pg_attribute a
WHERE c.oid = a.attrelid AND NOT a.attisdropped AND
a.atttypid = 'pg_catalog.unknown'::pg_catalog.regtype AND
c.relkind IN ('r','m','c') AND
c.relnamespace = n.oid AND
n.nspname !~ '^pg_temp_' AND
n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');
```
1. Perform a dry-run upgrade.
We highly recommend testing a major version upgrade on a duplicate of your production database before trying the upgrade on your production database. You can monitor the execution plans on the duplicate test instance for any possible execution plan regressions and to evaluate its performance. To create a duplicate test instance, you can either restore your database from a recent snapshot or clone your database. For more information, see [Restoring from a snapshot](aurora-restore-snapshot.md#aurora-restore-snapshot.Restoring) or [Cloning a volume for an Amazon Aurora DB cluster](Aurora.Managing.Clone.md).
For more information, see [Upgrading the Aurora PostgreSQL engine to a new major version](#USER_UpgradeDBInstance.Upgrading.Manual).
1. Upgrade your production instance.
When your dry-run major version upgrade is successful, you should be able to upgrade your production database with confidence. For more information, see [Upgrading the Aurora PostgreSQL engine to a new major version](#USER_UpgradeDBInstance.Upgrading.Manual).
**Note**
During the upgrade process, Aurora PostgreSQL takes a DB cluster snapshot. You can't do a point-in-time restore of your cluster during this process. Later, you can perform a point-in-time restore to times before the upgrade began and after the automatic snapshot of your instance has completed. However, you can't perform a point-in-time restore to a previous minor version.
For information about an upgrade in progress, you can use Amazon RDS to view two logs that the pg\$1upgrade utility produces. These are `pg_upgrade_internal.log` and `pg_upgrade_server.log`. Amazon Aurora appends a timestamp to the file name for these logs. You can view these logs as you can any other log. For more information, see [Monitoring Amazon Aurora log files](USER_LogAccess.md).
1. Upgrade PostgreSQL extensions. The PostgreSQL upgrade process doesn't upgrade any PostgreSQL extensions. For more information, see [Upgrading PostgreSQL extensions](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md).
## Post-upgrade recommendations
After you complete a major version upgrade, we recommend the following:
+ Run the `ANALYZE` operation to refresh the `pg_statistic` table. You should do this for every database on all your PostgreSQL DB instances. Optimizer statistics aren't transferred during a major version upgrade, so you need to regenerate all statistics to avoid performance issues. Run the command without any parameters to generate statistics for all regular tables in the current database, as follows:
```
ANALYZE VERBOSE;
```
The `VERBOSE` flag is optional, but using it shows you the progress. For more information, see [ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html) in the PostgreSQL documentation.
When analyzing specific tables instead of using ANALYZE VERBOSE, run the ANALYZE command for each table as follows:
```
ANALYZE table_name;
```
For partitioned tables, always analyze the parent table. This process:
+ Automatically samples rows across all partitions
+ Updates statistics for each partition recursively
+ Maintains essential planning statistics at the parent level
While parent tables store no actual data, analyzing them is vital for query optimization. Running ANALYZE only on individual partitions can lead to poor query performance since the optimizer won't have the comprehensive statistics needed for efficient cross-partition planning.
**Note**
Run ANALYZE on your system after the upgrade to avoid performance issues.
+ If you upgraded to PostgreSQL version 10, run `REINDEX` on any hash indexes you have. Hash indexes were changed in version 10 and must be rebuilt. To locate invalid hash indexes, run the following SQL for each database that contains hash indexes.
```
SELECT idx.indrelid::regclass AS table_name,
idx.indexrelid::regclass AS index_name
FROM pg_catalog.pg_index idx
JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid
JOIN pg_catalog.pg_am am ON am.oid = cls.relam
WHERE am.amname = 'hash'
AND NOT idx.indisvalid;
```
+ We recommend that you test your application on the upgraded database with a similar workload to verify that everything works as expected. After the upgrade is verified, you can delete this test instance.
## Upgrading the Aurora PostgreSQL engine to a new major version
When you initiate the upgrade process to a new major version, Aurora PostgreSQL takes a snapshot of the Aurora DB cluster before it makes any changes to your cluster. This snapshot is created for major version upgrades only, not minor version upgrades. When the upgrade process completes, you can find this snapshot among the manual snapshots listed under **Snapshots** in the RDS console. The snapshot name includes `preupgrade` as its prefix, the name of your Aurora PostgreSQL DB cluster, the source version, the target version, and the date and timestamp, as shown in the following example.
```
preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19
```
After the upgrade completes, you can use the snapshot that Aurora created and stored in your manual snapshot list to restore the DB cluster to its previous version, if necessary.
**Tip**
In general, snapshots provide many ways to restore your Aurora DB cluster to various points in time. To learn more, see [Restoring from a DB cluster snapshot](aurora-restore-snapshot.md) and [Restoring a DB cluster to a specified time](aurora-pitr.md). However, Aurora PostgreSQL doesn't support using a snapshot to restore to a previous minor version.
During the major version upgrade process, Aurora allocates a volume and clones the source Aurora PostgreSQL DB cluster. If the upgrade fails for any reason, Aurora PostgreSQL uses the clone to roll back the upgrade. After more than 15 clones of a source volume are allocated, subsequent clones become full copies and take longer. This can cause the upgrade process also to take longer. If Aurora PostgreSQL rolls back the upgrade, be aware of the following:
+ You might see billing entries and metrics for both the original volume and the cloned volume allocated during the upgrade. Aurora PostgreSQL cleans up the extra volume after the cluster backup retention window is beyond the time of the upgrade.
+ The next cross-Region snapshot copy from this cluster will be a full copy instead of an incremental copy.
To safely upgrade the DB instances that make up your cluster, Aurora PostgreSQL uses the pg\$1upgrade utility. After the writer upgrade completes, each reader instance experiences a brief outage while it's upgraded to the new major version. To learn more about this PostgreSQL utility, see [pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html) in the PostgreSQL documentation.
You can upgrade your Aurora PostgreSQL DB cluster to a new version by using the AWS Management Console, the AWS CLI, or the RDS API.
### Console
**To upgrade the engine version of a DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**, and then choose the DB cluster that you want to upgrade.
1. Choose **Modify**. The **Modify DB cluster** page appears.
1. For **Engine version**, choose the new version.
1. Choose **Continue** and check the summary of modifications.
1. To apply the changes immediately, choose **Apply immediately**. Choosing this option can cause an outage in some cases. For more information, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md).
1. On the confirmation page, review your changes. If they are correct, choose **Modify Cluster** to save your changes.
Or choose **Back** to edit your changes or **Cancel** to cancel your changes.
### AWS CLI
To upgrade the engine version of a DB cluster, use the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command. Specify the following parameters:
+ `--db-cluster-identifier` – The name of the DB cluster.
+ `--engine-version` – The version number of the database engine to upgrade to. For information about valid engine versions, use the AWS CLI [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) command.
+ `--allow-major-version-upgrade` – A required flag when the `--engine-version` parameter is a different major version than the DB cluster's current major version.
+ `--no-apply-immediately` – Apply changes during the next maintenance window. To apply changes immediately, use `--apply-immediately`.
**Example**
For Linux, macOS, or Unix:
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier mydbcluster \
3. --engine-version new_version \
4. --allow-major-version-upgrade \
5. --no-apply-immediately
```
For Windows:
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier mydbcluster ^
3. --engine-version new_version ^
4. --allow-major-version-upgrade ^
5. --no-apply-immediately
```
### RDS API
To upgrade the engine version of a DB cluster, use the [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) operation. Specify the following parameters:
+ `DBClusterIdentifier` – The name of the DB cluster, for example *`mydbcluster`*.
+ `EngineVersion` – The version number of the database engine to upgrade to. For information about valid engine versions, use the [ DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) operation.
+ `AllowMajorVersionUpgrade` – A required flag when the `EngineVersion` parameter is a different major version than the DB cluster's current major version.
+ `ApplyImmediately` – Whether to apply changes immediately or during the next maintenance window. To apply changes immediately, set the value to `true`. To apply changes during the next maintenance window, set the value to `false`.
### Major upgrades for global databases
For an Aurora global database cluster, the upgrade process upgrades all DB clusters that make up your Aurora global database at the same time. It does so to ensure that each runs the same Aurora PostgreSQL version. It also ensures that any changes to system tables, data file formats, and so on, are automatically replicated to all secondary clusters.
To upgrade a global database cluster to a new major version of Aurora PostgreSQL, we recommend that you test your applications on the upgraded version, as detailed in [Testing an upgrade of your production DB cluster to a new major version](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary). Be sure to prepare your DB cluster parameter group and DB parameter group settings for each AWS Region in your Aurora global database before the upgrade as detailed in [step 1.](#step-1) of [Testing an upgrade of your production DB cluster to a new major version](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
If your Aurora PostgreSQL global database cluster has a recovery point objective (RPO) set for its `rds.global_db_rpo` parameter, make sure to reset the parameter before upgrading. The major version upgrade process doesn't work if the RPO is turned on. By default, this parameter is turned off. For more information about Aurora PostgreSQL global databases and RPO, see [Managing RPOs for Aurora PostgreSQL–based global databases](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery).
If you verify that your applications can run as expected on the trial deployment of the new version, you can start the upgrade process. To do so, see [Upgrading the Aurora PostgreSQL engine to a new major version](#USER_UpgradeDBInstance.Upgrading.Manual). Be sure to choose the top-level item from the **Databases** list in the RDS console, **Global database**, as shown in the following image.
![\[Console image showing an Aurora global database, an Aurora Serverless DB cluster, and another Aurora PostgreSQL DB cluster\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-plus-other.png)
As with any modification, you can confirm that you want the process to proceed when prompted.
![\[Console image showing prompt to confirm the upgrade process for an Aurora PostgreSQL DB cluster\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-upgrade-2.png)
Rather than using the console, you can start the upgrade process by using the AWS CLI or the RDS API. As with the console, you operate on the Aurora global database cluster rather than any of its constituents, as follows:
+ Use the [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) AWS CLI command to start the upgrade for your Aurora global database by using the AWS CLI.
+ Use the [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) API to start the upgrade.
# Performing a minor version upgrade
You can use the following methods to upgrade the minor version of a DB cluster or to patch a DB cluster:
**Topics**
+ [Before performing a minor version upgrade](#USER_UpgradeDBInstance.PostgreSQL.BeforeMinor)
+ [How to perform minor version upgrades and apply patches](#USER_UpgradeDBInstance.PostgreSQL.Minor)
+ [Minor release upgrades and zero-downtime patching](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp)
+ [Limitations of zero-downtime patching](#USER_UpgradeDBInstance.PostgreSQL.Minor.zdp.limitations)
+ [Upgrading the Aurora PostgreSQL engine to a new minor version](#USER_UpgradeDBInstance.MinorUpgrade)
## Before performing a minor version upgrade
We recommend that you perform the following actions to reduce the downtime during a minor version upgrade:
+ The Aurora DB cluster maintenance should be performed during a period of low traffic. Use Performance Insights to identify these time periods in order to configure the maintenance windows correctly. For more information on Performance Insights, see [Monitoring DB load with Performance Insights on Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html). For more information on DB cluster maintenance window, [Adjusting the preferred DB cluster maintenance window](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
+ Use AWS SDKs that support exponential backoff and jitter as a best practice. For more information, see [Exponential Backoff And Jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/).
## How to perform minor version upgrades and apply patches
Minor version upgrades and patches become available in AWS Regions only after rigorous testing. Before releasing upgrades and patches, Aurora PostgreSQL tests to ensure that known security issues, bugs, and other issues that emerge after the release of the minor community version don't disrupt Aurora PostgreSQL fleet stability.
If you turn on **Enable auto minor version upgrade**, Aurora PostgreSQL periodically upgrades your DB cluster during your specified maintenance window. Make sure that the **Enable auto minor version upgrade** option is turned on for all instances in your Aurora PostgreSQL DB cluster. For information on how to set **Auto minor version upgrade**, and how the setting works when applied at the cluster and instance levels, see [Automatic minor version upgrades for Aurora DB clusters](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
Check the value of the **Enable auto minor version upgrade** option for all your Aurora PostgreSQL DB clusters by using the [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI command as follows.
```
aws rds describe-db-instances \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'
```
This query returns a list of all Aurora DB clusters and their instances with a `true` or `false` value for the status of the `AutoMinorVersionUpgrade` setting. The command assumes that you have your AWS CLI configured to target your default AWS Region.
For more information about the AmVU option and how to modify your Aurora DB cluster to use it, see [Automatic minor version upgrades for Aurora DB clusters](USER_UpgradeDBInstance.Maintenance.md#Aurora.Maintenance.AMVU).
You can upgrade your Aurora PostgreSQL DB clusters to new minor versions either by responding to maintenance tasks, or by modifying the cluster to use the new version.
You can identify any available upgrades or patches for your Aurora PostgreSQL DB clusters by using the RDS console and opening the **Recommendations** menu. There, you can find a list of various maintenance issues such as **Old minor versions**. Depending on your production environment, you can choose to **Schedule** the upgrade or take immediate action, by choosing **Apply now**, as shown following.
![\[Console image showing Recommendation to upgrade to a newer minor version.\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/images/apg-maintenance-upgrade-minor.png)
To learn more about how to maintain an Aurora DB cluster, including how to manually apply patches and minor version upgrades, see [Maintaining an Amazon Aurora DB cluster](USER_UpgradeDBInstance.Maintenance.md).
## Minor release upgrades and zero-downtime patching
Upgrading an Aurora PostgreSQL DB cluster involves the possibility of an outage. During the upgrade process, the database is shut down as it's being upgraded. If you start the upgrade while the database is busy, you lose all connections and transactions that the DB cluster is processing. If you wait until the database is idle to perform the upgrade, you might have to wait a long time.
The zero-downtime patching (ZDP) feature improves the upgrading process. With ZDP, both minor version upgrades and patches can be applied with minimal impact to your Aurora PostgreSQL DB cluster. ZDP is used when applying patches or newer minor version upgrades to Aurora PostgreSQL versions and other higher releases of these minor versions and newer major versions. That is, upgrading to new minor versions from any of these releases onward uses ZDP.
The following table shows the Aurora PostgreSQL versions and DB instance classes where ZDP is available:
| Version | db.r\$1 instance classes | db.t\$1 instance classes | db.x\$1 instance classes | db.serverless instance class |
| --- | --- | --- | --- | --- |
| 10.21 and higher versions | Yes | Yes | Yes | N/A |
| 11.16 and higher versions | Yes | Yes | Yes | N/A |
| 11.17 and higher versions | Yes | Yes | Yes | N/A |
| 12.11 and higher versions | Yes | Yes | Yes | N/A |
| 12.12 and higher versions | Yes | Yes | Yes | N/A |
| 13.7 and higher versions | Yes | Yes | Yes | N/A |
| 13.8 and higher versions | Yes | Yes | Yes | Yes |
| 14.3 and higher versions | Yes | Yes | Yes | N/A |
| 14.4 and higher versions | Yes | Yes | Yes | N/A |
| 14.5 and higher versions | Yes | Yes | Yes | Yes |
| 15.3 and higher versions | Yes | Yes | Yes | Yes |
| 16.1 and higher versions | Yes | Yes | Yes | Yes |
During the upgrade process using ZDP, the database engine looks for a quiet point to pause all new transactions. This action safeguards the database during patches and upgrades. To make sure that your applications run smoothly with paused transactions, we recommend integrating retry logic into your code. This approach ensures that the system can manage any brief downtime without failing and can retry the new transactions after the upgrade.
When ZDP completes successfully, application sessions are maintained except for those with dropped connections, and the database engine restarts while the upgrade is still in progress. Although the database engine restart can cause a temporary drop in throughput, this typically lasts only for a few seconds or at most, approximately one minute.
In some cases, zero-downtime patching (ZDP) might not succeed. For example, parameter changes that are in a `pending` state on your Aurora PostgreSQL DB cluster or its instances interfere with ZDP.
You can find metrics and events for ZDP operations in **Events** page in the console. The events include the start of the ZDP upgrade and completion of the upgrade. In this event you can find how long the process took, and the numbers of preserved and dropped connections that occurred during the restart. You can find details in your database error log.
## Limitations of zero-downtime patching
The following limitations apply to zero-downtime patching:
+ ZDP tries to preserve current client connections to your Aurora PostgreSQL writer instance throughout the Aurora PostgreSQL upgrade process. However, in the following cases, connections will be dropped for ZDP to complete:
+ Long running query or transactions are in progress.
+ Data definition language (DDL) statements are running.
+ Temporary tables or table locks are in use.
+ All sessions are listening on notification channels.
+ A cursor in ‘WITH HOLD’ status is in use.
+ TLSv1.1 connections are in use. Starting with Aurora PostgreSQL versions later than 16.1, 15.3, 14.8, 13.11, 12.15, and 11.20, ZDP is supported with TLSv1.3 connections.
+ ZDP isn't supported in the following cases:
+ During the upgrade of any Aurora reader instances.
+ During the upgrade of any Aurora reader instances that are part of an Aurora Global Database cluster in a secondary Region.
+ During OS patches and OS upgrades.
## Upgrading the Aurora PostgreSQL engine to a new minor version
You can upgrade your Aurora PostgreSQL DB cluster to a new minor version by using the console, the AWS CLI, or the RDS API. Before performing the upgrade, we recommend that you follow the same best practice that we recommend for major version upgrades. As with new major versions, new minor versions can also have optimizer improvements, such as fixes, that can cause query plan regressions. To ensure plan stability, we recommend that you use the Query Plan Management (QPM) extension as detailed in [Ensuring plan stability after a major version upgrade](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade).
### Console
**To upgrade the engine version of your Aurora PostgreSQL DB cluster**
1. Sign in to the AWS Management Console and open the Amazon RDS console at [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. In the navigation pane, choose **Databases**, and then choose the DB cluster that you want to upgrade.
1. Choose **Modify**. The **Modify DB cluster** page appears.
1. For **Engine version**, choose the new version.
1. Choose **Continue** and check the summary of modifications.
1. To apply the changes immediately, choose **Apply immediately**. Choosing this option can cause an outage in some cases. For more information, see [Modifying an Amazon Aurora DB cluster](Aurora.Modifying.md).
1. On the confirmation page, review your changes. If they are correct, choose **Modify Cluster** to save your changes.
Or choose **Back** to edit your changes or **Cancel** to cancel your changes.
### AWS CLI
To upgrade the engine version of a DB cluster, use the [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI command with the following parameters:
+ `--db-cluster-identifier` – The name of your Aurora PostgreSQL DB cluster.
+ `--engine-version` – The version number of the database engine to upgrade to. For information about valid engine versions, use the AWS CLI [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) command.
+ `--no-apply-immediately` – Apply changes during the next maintenance window. To apply changes immediately, use `--apply-immediately` instead.
For Linux, macOS, or Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier mydbcluster \
--engine-version new_version \
--no-apply-immediately
```
For Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier mydbcluster ^
--engine-version new_version ^
--no-apply-immediately
```
### RDS API
To upgrade the engine version of a DB cluster, use the [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) operation. Specify the following parameters:
+ `DBClusterIdentifier` – The name of the DB cluster, for example *`mydbcluster`*.
+ `EngineVersion` – The version number of the database engine to upgrade to. For information about valid engine versions, use the [ DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) operation.
+ `ApplyImmediately` – Whether to apply changes immediately or during the next maintenance window. To apply changes immediately, set the value to `true`. To apply changes during the next maintenance window, set the value to `false`.
# Upgrading PostgreSQL extensions
Upgrading your Aurora PostgreSQL DB cluster to a new major or minor version doesn't upgrade the PostgreSQL extensions at the same time. For most extensions, you upgrade the extension after the major or minor version upgrade completes. However, in some cases, you upgrade the extension before you upgrade the Aurora PostgreSQL DB engine. For more information, see the [list of extensions to update](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#upgrade-extensions) in [Testing an upgrade of your production DB cluster to a new major version](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary).
Installing PostgreSQL extensions requires `rds_superuser` privileges. Typically, an `rds_superuser` delegates permissions over specific extensions to relevant users (roles), to facilitate the management of a given extension. That means that the task of upgrading all the extensions in your Aurora PostgreSQL DB cluster might involve many different users (roles). Keep this in mind especially if you want to automate the upgrade process by using scripts. For more information about PostgreSQL privileges and roles, see [Security with Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md).
**Note**
For information about updating the PostGIS extension, see [Managing spatial data with the PostGIS extension](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md) ([Step 6: Upgrade the PostGIS extension](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)).
To update the `pg_repack` extension, drop the extension and then create the new version in the upgraded DB instance. For more information, see [pg\$1repack installation](https://reorg.github.io/pg_repack/) in the `pg_repack` documentation.
To update an extension after an engine upgrade, use the `ALTER EXTENSION UPDATE` command.
```
ALTER EXTENSION extension_name UPDATE TO 'new_version';
```
To list your currently installed extensions, use the PostgreSQL [pg\$1extension](https://www.postgresql.org/docs/current/catalog-pg-extension.html) catalog in the following command.
```
SELECT * FROM pg_extension;
```
To view a list of the specific extension versions that are available for your installation, use the PostgreSQL [ pg\$1available\$1extension\$1versions](https://www.postgresql.org/docs/current/view-pg-available-extension-versions.html) view in the following command.
```
SELECT * FROM pg_available_extension_versions;
```
## Alternative blue/green upgrade technique
In some situations, your top priority is to perform an immediate switchover from the old cluster to an upgraded one. In such situations, you can use a multistep process that runs the old and new clusters side-by-side. Here, you replicate data from the old cluster to the new one until you are ready for the new cluster to take over. For details, see [Using Amazon Aurora Blue/Green Deployments for database updates](blue-green-deployments.md).
# Using an Aurora PostgreSQL long-term support (LTS) release
Each new Aurora PostgreSQL version remains available for a certain amount of time for you to use when you create or upgrade a DB cluster. After this period, you must upgrade any clusters that use that version. You can manually upgrade your cluster before the support period ends, or Aurora can automatically upgrade it for you when its Aurora PostgreSQL version is no longer supported.
Aurora designates certain Aurora PostgreSQL versions as long-term support (LTS) releases. Database clusters that use LTS releases can stay on the same version longer and undergo fewer upgrade cycles than clusters that use non-LTS releases. LTS minor versions include only bug fixes (through patch versions) for critical stability and security issues; an LTS version doesn't include new features released after its introduction.
Once a year, DB clusters running on an LTS minor version are patched to the latest patch version of the LTS release. We do this patching to help ensure that you benefit from cumulative security and stability fixes. We might patch an LTS minor version more frequently if there are critical fixes, such as for security, that need to be applied.
**Note**
If you want to remain on an LTS minor version for the duration of its lifecycle, make sure to disable automatic minor version upgrade for your DB instances. To avoid automatically upgrading your DB cluster from the LTS minor version, clear the **Enable auto minor version upgrade** check box on any DB instance in your Aurora cluster.
We recommend that you upgrade to the latest release, instead of using the LTS release, for most of your Aurora PostgreSQL clusters. Doing so takes advantage of Aurora as a managed service and gives you access to the latest features and bug fixes. LTS releases are intended for clusters with the following characteristics:
+ You can't afford downtime on your Aurora PostgreSQL application for upgrades outside of rare occurrences for critical patches.
+ The testing cycle for the cluster and associated applications takes a long time for each update to the Aurora PostgreSQL database engine.
+ The database version for your Aurora PostgreSQL cluster has all the DB engine features and bug fixes that your application needs.
The current LTS releases for Aurora PostgreSQL are as follows:
+ PostgreSQL 17.7. It was released on March 25, 2026. For more information, see [ PostgreSQL 17.7](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version177x) in the *Release Notes for Aurora PostgreSQL*.
+ PostgreSQL 16.8. It was released on April 07, 2025. For more information, see [ PostgreSQL 16.8](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version168x) in the *Release Notes for Aurora PostgreSQL*.
+ PostgreSQL 15.10. It was released on December 27, 2024. For more information, see [ PostgreSQL 15.10](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#aurorapostgresql-versions-version1510x) in the *Release Notes for Aurora PostgreSQL*.
+ PostgreSQL 14.6. It was released on January 20, 2023. For more information, see [ PostgreSQL 14.6](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.146X) in the *Release Notes for Aurora PostgreSQL*.
+ PostgreSQL 13.9. It was released on January 20, 2023. For more information, see [ PostgreSQL 13.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.139X) in the *Release Notes for Aurora PostgreSQL*.
+ PostgreSQL 12.9. It was released on February 25, 2022. For more information, see [ PostgreSQL 12.9](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.129) in the *Release Notes for Aurora PostgreSQL*.
+ PostgreSQL 11.9 (Aurora PostgreSQL release 3.4. It was released on December 11, 2020. For more information about this version, see [ PostgreSQL 11.9, Aurora PostgreSQL release 3.4](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.34) in the *Release Notes for Aurora PostgreSQL*.
For details about support timelines and release cycles for the LTS versions, see [ Release calendars for Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/aurorapostgresql-release-calendar.html).
For information about how to identify Aurora and database engine versions, see [Identifying versions of Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.md#AuroraPostgreSQL.Updates.Versions).