Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Attività DBA comuni per Amazon RDS for PostgreSQL
Gli amministratori di database (DBAs) eseguono una serie di attività durante l'amministrazione di un'istanza database Amazon RDS for PostgreSQL. Se sei un amministratore di database (DBA) che già conosce PostgreSQL, devi essere a conoscenza di alcune delle principali differenze tra l'esecuzione di PostgreSQL sul tuo hardware e RDS per PostgreSQL. Ad esempio, poiché si tratta di un servizio gestito, Amazon RDS non consente alla shell di accedere alle istanze database. Ciò significa che non puoi accedere direttamente a `pg_hba.conf` e altri file di configurazione. Per RDS per PostgreSQL, le modifiche che vengono in genere apportate al file di configurazione PostgreSQL di un'istanza on-premise vengono applicate a un gruppo di parametri database personalizzato associato all'istanza database RDS per PostgreSQL. Per ulteriori informazioni, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md).
Non è possibile accedere ai file di log come con un'istanza PostgreSQL on-premise. Per ulteriori informazioni sulla registrazione, consulta [](USER_LogAccess.Concepts.PostgreSQL.md).
Come altro esempio, non è possibile accedere all'account PostgreSQL `superuser`. Su RDS per PostgreSQL, il ruolo `rds_superuser` è quello più privilegiato e viene concesso a `postgres` al momento della configurazione. Sia che tu abbia familiarità con l'utilizzo di PostgreSQL on-premise o che tu sia un nuovo utente di RDS per PostgreSQL, ti consigliamo di familiarizzare con il ruolo `rds_superuser` e approfondire l'utilizzo di ruoli, utenti, gruppi e autorizzazioni. Per ulteriori informazioni, consulta [Informazioni su ruoli e autorizzazioni di PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Di seguito sono riportate alcune attività DBA comuni per RDS for PostgreSQL.
**Topics**
+ [Collation supportate in PostgreSQL RDS per PostgreSQL](PostgreSQL-Collations.md)
+ [Informazioni su ruoli e autorizzazioni di PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md)
+ [Gestione delle connessioni interrotte in PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.md)
+ [Utilizzo della funzionalità di autovacuum di PostgreSQL in Amazon RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md)
+ [Gestione di un numero elevato di oggetti in Amazon RDS for PostgreSQL Amazon Aurora](PostgreSQL.HighObjectCount.md)
+ [](Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.md)
+ [Utilizzo dei meccanismi di registrazione supportati da RDS for PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Auditing)
+ [Gestione dei file temporanei con PostgreSQL](PostgreSQL.ManagingTempFiles.md)
+ [Utilizzo di pgBadger per l'analisi del registro con PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Badger)
+ [Utilizzo PGSnapper per il monitoraggio di PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.Snapper)
+ [](PostgreSQL.CustomCasts.md)
+ [Best practice per le query parallele in PostgreSQL RDS per PostgreSQL](PostgreSQL.ParallelQueries.md)
+ [Utilizzo dei parametri sull'istanza database RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md)
# Collation supportate in PostgreSQL RDS per PostgreSQL
Le regole di confronto sono un insieme di regole che determinano il modo in cui le stringhe di caratteri archiviate nel database vengono ordinate e confrontate. Le regole di confronto svolgono un ruolo fondamentale nel sistema del computer e sono incluse come parte del sistema operativo. Le regole di confronto cambiano nel tempo quando vengono aggiunti nuovi caratteri alle lingue o quando vengono modificate le regole di ordinamento.
Le librerie di regole di confronto definiscono regole e algoritmi specifici per una regola di confronto. Le librerie di regole di confronto più popolari utilizzate in PostgreSQL sono GNU C (glibc) e Internationalization components for Unicode (ICU). Per impostazione predefinita, RDS per PostgreSQL utilizza la regola di confronto glibc che include le sequenze di ordinamento dei caratteri unicode per sequenze di caratteri multibyte.
Quando si crea una nuova istanza database in RDS per PostgreSQL, viene cercata la regola di confronto disponibile nel sistema operativo. I parametri PostgreSQL `LC_COLLATE` e `LC_CTYPE` del comando `CREATE DATABASE` vengono utilizzati per specificare una regola di confronto, che rappresenta la regola di confronto predefinita nel database. In alternativa, puoi anche usare il parametro `LOCALE` in `CREATE DATABASE` per impostare questi parametri e determinare la regole di confronto predefinita per le stringhe di caratteri nel database e le regole per classificare i caratteri come lettere, numeri o simboli. Puoi anche scegliere una regola di confronto da utilizzare per una colonna, un indice o una query.
RDS per PostgreSQL dipende dalla libreria glibc del sistema operativo per il supporto della regola di confronto. L'istanza RDS per PostgreSQL viene aggiornata periodicamente con le versioni più recenti del sistema operativo. Questi aggiornamenti a volte includono una nuova versione della libreria glibc. Raramente, le versioni più recenti della libreria glibc modificano l'ordinamento o la regola di confronto di alcuni caratteri e pertanto i dati possono essere ordinati in modo diverso o produrre voci di indice non valide. Se si riscontrano problemi di ordinamento per la regola di confronto durante un aggiornamento, potrebbe essere necessario ricostruire gli indici.
Per ridurre il possibile impatto degli aggiornamenti della libreria glibc, RDS per PostgreSQL ora include una libreria di regole di confronto predefinita indipendente. Questa libreria di regole confronto è disponibile in RDS for PostgreSQL 14.6, 13.9, 12.13, 11.18, 10.23 e versioni secondarie successive. È compatibile con glibc 2.26-59.amzn2 e fornisce stabilità dell'ordinamento per evitare risultati errati delle query.
# Informazioni su ruoli e autorizzazioni di PostgreSQL
Quando si crea un' per PostgreSQL utilizzando, viene creato contemporaneamente un account amministratore. Console di gestione AWS Per impostazione predefinita, verrà chiamato `postgres`, come mostrato nello screenshot seguente:
![\[L'identità di accesso predefinita per le credenziali nella pagina Create database (Crea database) è postgres.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/default-login-identity-apg-rpg.png)
Anziché accettare il valore predefinito (`postgres`) è possibile scegliere un nome diverso. In tal caso, il nome scelto deve iniziare con una lettera e contenere da 1 a 16 caratteri alfanumerici. Per semplicità, facciamo riferimento a questo account utente principale utilizzando il suo valore predefinito (`postgres`) in tutta la Guida.
Se si utilizza il `create-db-instance` AWS CLI anziché il Console di gestione AWS, si crea il nome passandolo con il parametro nel comando. `master-username` Per ulteriori informazioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md).
Sia che utilizzi l' Console di gestione AWS API Amazon RDS AWS CLI, che utilizzi il `postgres` nome predefinito o scelga un nome diverso, questo primo account utente del database è membro del `rds_superuser` gruppo e dispone di `rds_superuser` privilegi.
**Topics**
+ [Comprendere il ruolo rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Controllo dell'accesso utente al database PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Delega e controllo della gestione delle password utente](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Utilizzo delle crittografia password SCRAM per PostgreSQL](PostgreSQL_Password_Encryption_configuration.md)
# Comprendere il ruolo rds\$1superuser
In PostgreSQL, un *ruolo* può definire un utente, un gruppo o un insieme di autorizzazioni specifiche concesse a un gruppo o a un utente per vari oggetti nel database. I comandi PostgreSQL `CREATE USER` e `CREATE GROUP` sono stati sostituiti dal comando `CREATE ROLE` più generico, ma con proprietà specifiche per distinguere gli utenti del database. Un utente del database può essere paragonato a un ruolo con il privilegio LOGIN.
**Nota**
È comunque possibile continuare a utilizzare i comandi `CREATE USER` e `CREATE GROUP`. Per ulteriori informazioni, consulta la sezione relativa ai [ruoli di database](https://www.postgresql.org/docs/current/user-manag.html) nella documentazione di PostgreSQL.
L'utente `postgres` è l'utente di database più privilegiato nell'istanza database di RDS per PostgreSQL. Ha le caratteristiche definite dalla seguente istruzione `CREATE ROLE`.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Le proprietà `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` e `VALID UNTIL 'infinity'` sono le opzioni predefinite per CREATE ROLE, se non diversamente specificato.
Per impostazione predefinita, `postgres` dispone dei privilegi concessi al `rds_superuser` ruolo e delle autorizzazioni per creare ruoli e database. Il ruolo `rds_superuser` consente all'utente `postgres` di eseguire le seguenti operazioni:
+ Aggiungere le estensioni che sono disponibili per l'uso con Amazon RDS. Per ulteriori informazioni, consulta [Utilizzo delle caratteristiche di PostgreSQL supportate da Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.md)
+ Creare ruoli per gli utenti e concedere i relativi privilegi. Per ulteriori informazioni, consulta [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) e [GRANT](https://www.postgresql.org/docs/14/sql-grant.html)nella documentazione di PostgreSQL.
+ Creare database. Per ulteriori informazioni, consulta [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) nella documentazione di PostgreSQL.
+ Concedere privilegi `rds_superuser` a ruoli utente che non dispongono di questi privilegi e revocare i privilegi, se necessario. Si consiglia di concedere questo ruolo solo agli utenti che eseguono attività superuser. In altre parole, è possibile concedere questo ruolo agli amministratori del database (DBAs) o agli amministratori di sistema.
+ Concedere (e revocare) il ruolo `rds_replication` per gli utenti del database che non hanno il ruolo `rds_superuser`.
+ Concedere (e revocare) il ruolo `rds_password` per gli utenti del database che non hanno il ruolo `rds_superuser`.
+ Ottenere informazioni sullo stato di tutte le connessioni al database utilizzando la vista `pg_stat_activity`. Quando necessario, il ruolo `rds_superuser` può arrestare qualsiasi connessione utilizzando il comando `pg_terminate_backend` o `pg_cancel_backend`.
Nell'istruzione `CREATE ROLE postgres...`, si può vedere che il ruolo utente `postgres` non concede specificamente autorizzazioni PostgreSQL `superuser`. RDS per PostgreSQL è un servizio gestito e pertanto non è possibile accedere al sistema operativo host, né connettersi utilizzando l'account PostgreSQL`superuser`. Molte delle attività che richiedono l'accesso di tipo `superuser` su un PostgreSQL autonomo viene gestito automaticamente da Amazon RDS.
Per ulteriori informazioni sulla concessione dei privilegi, consulta la sezione relativa al comando [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) nella documentazione di PostgreSQL.
Il ruolo `rds_superuser` è uno dei diversi ruoli *predefinito* in un Istanza database di RDS per PostgreSQL.
**Nota**
In PostgreSQL 13 e versioni precedenti, i ruoli di *default* sono conosciuti come ruoli *predefiniti*.
L'elenco seguente fornisce alcuni degli altri ruoli predefiniti creati automaticamente per un nuovo . Istanza database di RDS per PostgreSQL. I ruoli predefiniti e i relativi privilegi non possono essere modificati. Non è possibile eliminare, rinominare o modificare i privilegi per questi ruoli predefiniti. Qualsiasi tentativo comporta la generazione di un errore.
+ **rds\$1password** - Un ruolo in grado di modificare le password e configurare vincoli di password per gli utenti del database. Questo ruolo `rds_superuser` viene assegnato al ruolo per impostazione predefinita e può concedere il ruolo agli utenti del database. Per ulteriori informazioni, consulta [Controllo dell'accesso utente al database PostgreSQLControllo dell'accesso utente a PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Per le versioni di RDS per PostgreSQL precedenti alla 14, il ruolo `rds_password` può modificare le password e configurare vincoli di password per gli utenti del database e gli utenti con ruolo `rds_superuser`. A partire dalla versione 14 di RDS per PostgreSQL, il ruolo `rds_password` può modificare le password e configurare vincoli di password solo per gli utenti del database. Solo gli utenti con ruolo `rds_superuser` possono eseguire queste azioni su altri utenti con ruolo `rds_superuser`.
+ **rdsadmin** – Un ruolo creato per gestire molte delle attività di gestione che l'amministratore con privilegi `superuser` esegue su un database PostgreSQL autonomo. Questo ruolo viene utilizzato internamente da RDS per PostgreSQL per molte attività di gestione.
+ **rdstopmgr**: un ruolo utilizzato internamente da Amazon RDS per supportare le implementazioni multi-AZ.
+ **rds\$1reserved**: un ruolo utilizzato internamente da Amazon RDS per prenotare le connessioni al database.
# Visualizzazione dei ruoli e dei relativi privilegi
È possibile visualizzare i ruoli predefiniti e i relativi privilegi nell’istanza database RDS per PostgreSQL utilizzando comandi diversi a seconda della versione di PostgreSQL in uso. Per visualizzare tutti i ruoli predefiniti, è possibile connettersi a un’istanza database RDS per PostgreSQL ed eseguire i comandi riportati di seguito tramite `psql`.
**Per `psql` versione 15 e precedenti**
Connettiti a un’istanza database RDS per PostgreSQL e utilizza il comando `\du` in psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Per `psql` versione 16 e successive**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Per verificare l’appartenenza ai ruoli senza dipendenza dalla versione, puoi utilizzare la seguente query SQL:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Nell'output, si vede che `rds_superuser` non è un ruolo utente del database (non può effettuare il login), ma ha i privilegi di molti altri ruoli. È inoltre possibile vedere che l'utente di database `postgres` è membro del ruolo `rds_superuser`. Come accennato in precedenza, `postgres` è il valore predefinito nella pagina **Crea database** della console Amazon RDS. Se si sceglie un altro nome, tale nome viene visualizzato nell'elenco dei ruoli.
# Controllo dell'accesso utente al database PostgreSQL
I nuovi database in PostgreSQL vengono sempre creati con un set predefinito di privilegi nel schema `public` del database, che consente a tutti gli utenti e i ruoli del database di creare oggetti. I privilegi predefiniti permettono agli utenti del database di connettersi al database e di creare tabelle temporanee durante la connessione.
Per controllare meglio l'accesso degli utenti alle istanze database create sull'istanza database RDS per PostgreSQL, si consiglia di revocare questi privilegi `public` predefiniti. Dopo averlo fatto, è consigliabile concedere privilegi specifici agli utenti del database su base più granulare, come mostrato nella procedura seguente.
**Per impostare ruoli e privilegi per una nuova istanza database**
Si supponga di aver configurando un database in un'istanza database RDS per PostgreSQL per poter essere usato da diversi ricercatori, che dovranno avere l'accesso in lettura-scrittura al database.
1. Utilizzare `psql` (o pgAdmin) per connettersi all'istanza database RDS per PostgreSQL:
```
psql --host=your-db-instance.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Specifica la password, quando richiesto. Il client `psql` si connette e visualizza il database di connessione amministrativa predefinito `postgres=>` come prompt.
1. Per impedire agli utenti del database di creare oggetti nello schema `public`, eseguire le seguenti operazioni:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Creare quindi una nuova istanza database:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Revocare tutti i privilegi dallo schema `PUBLIC` in questo nuovo database.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Creare un ruolo per gli utenti del database.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Concedere agli utenti del database con questo ruolo la possibilità di connettersi al database.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Concedere a tutti gli utenti con il ruolo `lab_tech` tutti i privilegi per questo database.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Creare utenti del database, come segue:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Concedere a questi due utenti i privilegi associati al ruolo lab\$1tech:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
A questo punto, `lab_user1` e `lab_user2` possono connettersi al database `lab_db`. Questo esempio non segue le best practice per l'utilizzo aziendale, che potrebbero includere la creazione di più istanze database, schemi diversi e la concessione di autorizzazioni limitate. Per informazioni più complete e scenari aggiuntivi, consulta [Gestione di utenti e ruoli PostgreSQL](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Per ulteriori informazioni sui privilegi in database PostgreSQL, consulta la sezione relativa al comando [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) nella documentazione di PostgreSQL.
# Delega e controllo della gestione delle password utente
Un amministratore di database (DBA) potrebbe voler delegare la gestione delle password utente. In alternativa, è possibile impedire agli utenti del database di modificare le password o di riconfigurare i vincoli delle password, ad esempio la durata della password. Per garantire che solo gli utenti del database scelti possano modificare le impostazioni della password, è possibile attivare la funzione di gestione delle password con restrizioni. Quando si attiva questa funzione, solo gli utenti del database a cui è stato concesso il ruolo `rds_password` saranno in grado di gestire le password.
**Nota**
Per utilizzare la gestione delle password limitate, l'istanza database RDS per PostgreSQL deve eseguire PostgreSQL 10.6 o superiore.
Per impostazione predefinita, questa funzione è impostata su `off`, come mostrato di seguito:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Per attivare questa funzione, utilizzare un gruppo di parametri personalizzato e modificare l'impostazione per `rds.restrict_password_commands` su 1. Assicurarsi di riavviare l'istanza database RDS per PostgreSQL per implementare l'impostazione.
Con questa funzione attiva, i privilegi `rds_password` sono obbligatori per i seguenti comandi SQL:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
La ridenominazione di un role (`ALTER ROLE myrole RENAME TO newname`) è inoltre limitata se la password utilizza l'algoritmo di MD5 hashing.
Con questa funzionalità attiva, se si tenta di eseguire uno di questi comandi SQL senza le autorizzazioni di ruolo `rds_password`, viene generato il seguente errore:
```
ERROR: must be a member of rds_password to alter passwords
```
Si consiglia di concedere i privilegi `rds_password` solo a ruoli utilizzati esclusivamente per la gestione delle password. Se si concedono i privilegi `rds_password` agli utenti del database sprovvisti dei privilegi `rds_superuser`, è necessario concedere loro anche l'attributo `CREATEROLE`.
Assicurarsi di verificare i requisiti della password come la scadenza e la complessità necessaria sul lato client. Se si utilizza la propria utilità lato client per le modifiche relative alla password, l'utilità deve essere membro di `rds_password` e avere i privilegi `CREATE ROLE`.
# Utilizzo delle crittografia password SCRAM per PostgreSQL
Il *Salted Challenge Response Authentication Mechanism (SCRAM)* è un'alternativa all'algoritmo Message Digest (MD5) predefinito di PostgreSQL per la crittografia delle password. Il meccanismo di autenticazione SCRAM è considerato più sicuro di. MD5 Per ulteriori informazioni su questi due diversi approcci di protezione delle password, consulta la sezione relativa alla [autenticazione password](https://www.postgresql.org/docs/14/auth-password.html) nella documentazione di PostgreSQL.
Si consiglia di utilizzare SCRAM anziché MD5 come schema di crittografia delle password per il cluster DB. l’istanza database RDS per PostgreSQL. È un meccanismo crittografico di richiesta/risposta che utilizza l'algoritmo scram-sha-256 per l'autenticazione e la crittografia delle password.
Potrebbe essere necessario aggiornare le librerie per le applicazioni client per supportare SCRAM. Ad esempio, le versioni JDBC precedenti alla 42.2.0 non supportano SCRAM. Per ulteriori informazioni, consulta [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) nella documentazione di PostgreSQL JDBC Driver. Per un elenco di altri driver PostgreSQL e il supporto SCRAM, consulta [Elenco dei driver](https://wiki.postgresql.org/wiki/List_of_drivers) nella documentazione di PostgreSQL.
RDS per PostgreSQL versione 13.1 e successive supportano scram-sha-256. Queste versioni consentono inoltre di configurare l'istanza database per richiedere SCRAM, come illustrato nelle procedure seguenti.
## Configurazione del SCRAM
puoi richiedere che l'istanza database di RDS per PostgreSQL accetti solo password che utilizzano l'algoritmo scram-sha-256.
**Importante**
Per i proxy RDS esistenti con database PostgreSQL, se si modifica l'autenticazione del database in modo da utilizzare solo `SCRAM`, il proxy diventa non disponibile per un massimo di 60 secondi. Per evitare il problema, procedi in uno dei seguenti modi:
Assicurati che il database consenta entrambe le autenticazioni `SCRAM` e `MD5`.
Per utilizzare solo l'autenticazione `SCRAM`, crea un nuovo proxy, esegui la migrazione del traffico dell'applicazione sul nuovo proxy, quindi elimina il proxy precedentemente associato al database.
Prima di apportare modifiche al sistema, assicurati di comprendere il processo completo, come segue:
+ Ottieni informazioni su tutti i ruoli e la crittografia password per tutti gli utenti del database.
+ Verifica le impostazioni dei parametri per l'istanza database di RDS per PostgreSQL per i parametri che controllano la crittografia password.
+ Se l'istanza database di RDS per PostgreSQL utilizza un gruppo di parametri predefinito, devi creare un gruppo di parametri database e applicarlo all'istanza database di RDS per PostgreSQL in modo da poter modificare i parametri quando necessario. Se l'istanza database di RDS per PostgreSQL utilizza un gruppo di parametri personalizzati, puoi modificare i parametri necessari in seguito nel processo, in base alle esigenze.
+ Modifica il parametro `password_encryption` in `scram-sha-256`.
+ Invia una notifica a tutti gli utenti del database per informarli che devono aggiornare le password. Esegui la stessa operazione per l'account `postgres`. Le nuove password sono crittografate e archiviate utilizzando l'algoritmo scram-sha-256.
+ Verifica che tutte le password siano crittografate utilizzando come il tipo di crittografia.
+ Se tutte le password utilizzano scram-sha-256, puoi modificare il `rds.accepted_password_auth_method` da `md5+scram` a `scram-sha-256`.
**avvertimento**
Dopo aver modificato `rds.accepted_password_auth_method` in scram-sha-256, gli eventuali utenti (ruoli) con password crittografate `md5` non potranno connettersi.
### Prepararsi a richiedere SCRAM per l'
Prima di apportare modifiche all'istanza database RDS per PostgreSQL, controlla tutti gli account utente del database esistenti. Inoltre, controlla il tipo di crittografia utilizzato per le password. Puoi eseguire queste attività utilizzando l'estensione `rds_tools`. Per vedere quali versioni di PostgreSQL supportano `rds_tools`, consulta [Versioni delle estensioni per Amazon RDS per PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**Per ottenere un elenco di utenti del database (ruoli) e metodi di crittografia password**
1. Utilizza `psql` per connetterti all'istanza database RDS per PostgreSQL, come mostrato di seguito.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Installa l’estensione `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Ottieni un elenco di ruoli e crittografia.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
L'output visualizzato è simile al seguente.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Creazione di un gruppo di parametri DB personalizzato
**Nota**
Se l'istanza database di RDS per PostgreSQL utilizza già un gruppo di parametri personalizzati, non è necessario crearne uno nuovo.
Per una panoramica dei gruppi di parametri per Amazon RDS, consulta [Utilizzo dei parametri sull'istanza database RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Parameters.md).
Il tipo di crittografia password utilizzato per le password è impostato in un parametro, `password_encryption`. La crittografia consentita dall'istanza database di RDS per PostgreSQL è impostata in un altro parametro, `rds.accepted_password_auth_method`. La modifica di uno di questi rispetto ai valori predefiniti richiede la creazione di un gruppo di parametri database personalizzato e l'applicazione all'istanza.
Per ulteriori informazioni, consulta
Ora puoi associare il gruppo di parametri personalizzati all'istanza database.
**Per creare un gruppo di parametri di DB)**
1. Utilizza il comando CLI `[create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) ` per creare il gruppo di parametri database personalizzato. Questo esempio utilizza `postgres13` come l'origine per questo gruppo di parametri personalizzati.
Per Linux, macOS o Unix:
```
aws rds create-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family postgres13 --description 'Custom parameter group for SCRAM'
```
Per Windows:
```
aws rds create-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family postgres13 --description "Custom DB parameter group for SCRAM"
```
1. Utilizza il comando CLI `[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)` per applicare questo gruppo di parametri personalizzati al cluster database RDS per PostgreSQL.
Per Linux, macOS o Unix:
```
aws rds modify-db-instance --db-instance-identifier 'your-instance-name' \
--db-parameter-group-name "docs-lab-scram-passwords
```
Per Windows:
```
aws rds modify-db-instance --db-instance-identifier "your-instance-name" ^
--db-parameter-group-name "docs-lab-scram-passwords
```
Per ripetere la sincronizzazione dell'istanza database RDS per PostgreSQL con il gruppo di parametri DB personalizzato, è necessario riavviare l'istanza principale e tutte le altre istanze del cluster. Per ridurre al minimo l'impatto sugli utenti, pianifica questa operazione in modo che si verifichi durante la normale finestra di manutenzione.
### Configurazione della crittografia password per utilizzare SCRAM
Il meccanismo di crittografia password utilizzato da un'istanza database RDS per PostgreSQL è impostato nel gruppo di parametri DB nel parametro `password_encryption`. I valori consentiti sono unset, `md5` o `scram-sha-256`. Il valore predefinito dipende dalla versione di RDS per PostgreSQL come segue:
+ RDS per PostgreSQL 14 e versioni successive: l'impostazione predefinita è `scram-sha-256`
+ RDS per PostgreSQL 13: l'impostazione predefinita è `md5`
Con un gruppo di parametri database personalizzato collegato all'istanza database di RDS per PostgreSQL, puoi modificare i valori per il parametro di crittografia password.
![\[Di seguito, la console RDS mostra i valori predefiniti per i parametri password_encryption per RDS per PostgreSQL.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/rpg-pwd-encryption-md5-scram-1.png)
**Per modificare l'impostazione di crittografia password in scram-sha-256**
+ Modifica il valore della crittografia password in scram-sha-256, come mostrato di seguito. La modifica può essere applicata immediatamente perché il parametro è dinamico, quindi non è necessario un riavvio per rendere effettiva la modifica.
Per Linux, macOS o Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Per Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migrazione delle password per i ruoli utente in SCRAM
Puoi migrare le password per i ruoli utente a SCRAM come descritto di seguito.
**Per migrare le password degli utenti (ruoli) del database da a SCRAM MD5**
1. Accedi come utente amministratore (nome utente predefinito, `postgres`) come mostrato di seguito.
```
psql --host=db-name.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Controlla l'impostazione del parametro `password_encryption` sull'istanza database RDS per PostgreSQL utilizzando il comando seguente.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Modifica il valore di questo parametro in scram-sha-256. Per ulteriori informazioni, consulta [Configurazione della crittografia password per utilizzare SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Controlla nuovamente il valore per essere certo che ora sia impostato su `scram-sha-256`, come descritto di seguito.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Invia una notifica a tutti gli utenti del database con la richiesta di modificare le password. Assicurati di modificare anche la password per l'account `postgres` (l'utente del database con privilegi `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Ripeti il processo per tutti i database sul l’istanza database RDS per PostgreSQL.
### Modifica del parametro per richiedere SCRAM
Questo è il passaggio finale del processo. Dopo aver apportato la modifica nella procedura seguente, gli eventuali account utente (ruoli) che ancora utilizzano la crittografia `md5` per le password non possono accedere al l’istanza database RDS per PostgreSQL.
Il `rds.accepted_password_auth_method` specifica il metodo di crittografia accettato dall'istanza database di RDS per PostgreSQL per una password utente durante il processo di accesso. Il valore predefinito è `md5+scram`, il che significa che entrambi i metodi sono accettati. Nell'immagine seguente, è disponibile l'impostazione predefinita per questo parametro.
![\[La console RDS che mostra i valori predefiniti e consentiti per i parametri rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/pwd-encryption-md5-scram-2.png)
I valori consentiti per questo parametro sono `md5+scram` o `scram`. La modifica del valore di questo parametro in `scram` lo rende un requisito.
**Modificare il valore del parametro per richiedere l'autenticazione SCRAM per le password**
1. Verifica che tutte le password degli utenti del database per tutti i database sull'istanza database di RDS per PostgreSQL utilizzino `scram-sha-256` per la crittografia password. A questo proposito, esegui la query su `rds_tools` per il ruolo (utente) e il tipo di crittografia, come segue.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Ripeti la query su tutte le istanze database nel l’istanza database RDS per PostgreSQL.
Se tutte le password utilizzano scram-sha-256, puoi procedere.
1. Modifica il valore dell’autenticazione password accettata in scram-sha-256, come riportato di seguito.
Per Linux, macOS o Unix:
```
aws rds modify-db-parameter-group --db-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Per Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
# Gestione delle connessioni interrotte in PostgreSQL
Le connessioni interrotte si verificano quando una sessione di database rimane attiva sul server nonostante l’applicazione client sia stata abbandonata o terminata in modo anomalo. Questa situazione si verifica in genere quando i processi client vanno in crash o vengono terminati in modo imprevisto senza chiudere correttamente le connessioni al database o annullare le richieste in corso.
PostgreSQL esegue efficacemente l’identificazione e la pulizia delle connessioni interrotte quando i processi del server sono inattivi o tentano di inviare dati ai client. Tuttavia il rilevamento è complesso per le sessioni inattive, in attesa dell’input del client, o che eseguono attivamente le query. Per gestire questi scenari, PostgreSQL fornisce i parametri `tcp_keepalives_*`, `tcp_user_timeout` e `client_connection_check_interval`.
**Topics**
+ [Informazioni sui keepalive TCP](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Understanding)
+ [Principali parametri keepalive TCP in RDS per PostgreSQL](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.Parameters)
+ [Casi d’uso per le impostazioni keepalive TCP](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.UseCases)
+ [Best practice](#Appendix.PostgreSQL.CommonDBATasks.DeadConnectionHandling.BestPractices)
## Informazioni sui keepalive TCP
Keepalive TCP è un meccanismo a livello di protocollo che aiuta a mantenere e verificare l’integrità della connessione. Ogni connessione TCP mantiene le impostazioni a livello di kernel che regolano il comportamento di keepalive. Quando il timer keepalive scade, il sistema effettua le seguenti operazioni:
+ Invia un pacchetto di esplorazione senza dati e con il flag ACK impostato.
+ Prevede una risposta dall'endpoint remoto in base alle TCP/IP specifiche.
+ Gestisce lo stato della connessione in base alla risposta o alla sua mancanza.
## Principali parametri keepalive TCP in RDS per PostgreSQL
| Parametro | Description | Valori predefiniti |
| --- |--- |--- |
| tcp\$1keepalives\$1idle | Speciifica il numero di secondi di inattività prima dell'invio del messaggio keepalive. | 300 |
| tcp\$1keepalives\$1interval | Speciifica il numero di secondi tra le ritrasmissioni di messaggi keepalive non riconosciuti. | 30 |
| tcp\$1keepalives\$1count | Numero massimo di messaggi keepalive persi prima di dichiarare interrotta la connessione | 2 |
| tcp\$1user\$1timeout | Speciifica per quanto tempo (in millisecondi) possono rimanere i dati non riconosciuti prima della chiusura forzata della connessione. | 0 |
| client\$1connection\$1check\$1interval | Imposta l'intervallo (in millisecondi) per il controllo dello stato della connessione del client durante le query di lunga durata. Ciò garantisce un rilevamento più rapido delle connessioni chiuse. | 0 |
## Casi d’uso per le impostazioni keepalive TCP
### Keepalive per le sessioni inattive
Per evitare che le connessioni inattive vengano terminate da firewall o router a causa dell’inattività, procedi come segue:
+ Configura `tcp_keepalives_idle` per inviare pacchetti keepalive a intervalli regolari.
### Rilevamento di connessioni interrotte
Per rilevare tempestivamente le connessioni interrotte, procedi come segue:
+ Regola `tcp_keepalives_idle`, `tcp_keepalives_interval` e `tcp_keepalives_count`. Ad esempio, con le impostazioni predefinite di Aurora PostgreSQL, è necessario circa un minuto (2 sonde × 30 secondi) per rilevare una connessione interrotta. Riducendo questi valori è possibile velocizzare il rilevamento.
+ Utilizza `tcp_user_timeout` per specificare il tempo di attesa massimo per un riconoscimento.
Le impostazioni keepalive TCP aiutano il kernel a rilevare le connessioni interrotte, ma PostgreSQL potrebbe non agire finché non viene utilizzato il socket. Se una sessione esegue una query di lunga durata, le connessioni interrotte potrebbero essere rilevate solo dopo il completamento della query. In PostgreSQL 14 e versioni successive, `client_connection_check_interval` può accelerare il rilevamento delle connessioni interrotte tramite polling periodico del socket durante l’esecuzione della query.
## Best practice
+ **Imposta intervalli keepalive ragionevoli:** ottimizza `tcp_user_timeout`, `tcp_keepalives_idle`, `tcp_keepalives_count` e `tcp_keepalives_interval` per bilanciare la velocità di rilevamento e l’utilizzo delle risorse.
+ **Ottimizza per il tuo ambiente:** allinea le impostazioni al comportamento della rete, alle policy del firewall e alle esigenze delle sessioni.
+ **Sfrutta le funzionalità di PostgreSQL:** utilizza `client_connection_check_interval` in PostgreSQL 14 e versioni successive per controlli di connessione efficienti.
# Utilizzo della funzionalità di autovacuum di PostgreSQL in Amazon RDS per PostgreSQL
Consigliamo vivamente di usare la caratteristica di autovacuum per mantenere l'integrità dell'istanza database di PostgreSQL. La funzione di autovaacuum automatizza l'esecuzione del comando VACUUM e ANALYZE. Verifica la presenza di tabelle con un numero elevato di tuple inserite, aggiornate o eliminate. Dopo questa verifica, recupera lo storage rimuovendo i dati obsoleti o le tuple da database PostgreSQL.
Per impostazione predefinita, la funzionalità di autovacuum è abilitata per le istanze database di RDS per PostgreSQL create utilizzando uno dei gruppi di parametri di database PostgreSQL predefiniti. Per impostazione predefinita vengono impostati anche altri parametri di configurazione associati alla caratteristica di autovacuum. Poiché questi valori di default sono in qualche modo generici, è possibile trarre vantaggio dalla regolazione di alcuni parametri associati alla caratteristica di autovacuum per il carico di lavoro specifico.
Di seguito, puoi trovare ulteriori informazioni sulla funzionalità di autovacuum e su come regolare alcuni dei relativi parametri sulla tua istanza database di RDS per PostgreSQL. Per informazioni generali, consulta [Best practice per l'utilizzo di PostgreSQL](CHAP_BestPractices.md#CHAP_BestPractices.PostgreSQL).
**Topics**
+ [Allocazione di memoria per il vacuum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.WorkMemory)
+ [Riduzione della probabilità che si verifichi il wraparound dell’ID delle transazioni](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming)
+ [Determinare se le tabelle nel database devono essere sottoposte a vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.NeedVacuuming.md)
+ [Determinare quali tabelle sono attualmente idonee per l'Autovacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.EligibleTables.md)
+ [Determinare se l'Auotvacuum è attualmente in esecuzione e per quanto tempo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AutovacuumRunning.md)
+ [Esecuzione di un congelamento manuale del vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md)
+ [Indicizzare di nuovo una tabella quando l'autovacuum è in esecuzione](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Reindexing.md)
+ [Gestione di autovacuum con indici di grandi dimensioni](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md)
+ [Altri parametri che influenzano l'autovacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.OtherParms.md)
+ [Impostazione dei parametri di autovacuum a livello tabella](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.TableParameters.md)
+ [Registrazione delle attività di autovacuum e vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md)
+ [Comprensione del comportamento della funzionalità di autovacuum con database non validi](appendix.postgresql.commondbatasks.autovacuumbehavior.md)
+ [Identificazione e risoluzione dei blocchi per i processi di vacuum aggressivi in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.md)
## Allocazione di memoria per il vacuum
Uno dei parametri più importanti che influenzano le prestazioni dell'autovacuum è il parametro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM). Nelle versioni 14 e precedenti di RDS per PostgreSQL, il parametro `autovacuum_work_mem` è impostato su -1, a indicare che al suo posto viene utilizzata l’impostazione `maintenance_work_mem`. Per tutte le altre versioni, `autovacuum_work_mem` è determinato da GREATEST (\$1DBInstanceClassMemory/32768\$1, 65536).
Le operazioni manuali di aspirazione utilizzano sempre l'`maintenance_work_mem`impostazione, con un'impostazione predefinita di GREATEST (\$1DBInstanceClassMemory/63963136 \$11024\$1, 65536), e può anche essere regolata a livello di sessione utilizzando il comando per operazioni manuali più mirate. `SET` `VACUUM`
`autovacuum_work_mem` determina la memoria di autovacuum per contenere gli identificatori delle tuple inattive (`pg_stat_all_tables.n_dead_tup`) per gli indici dell’attività di vacuum.
Quando esegui i calcoli per determinare il valore del parametro `autovacuum_work_mem`, tieni presente quanto segue:
+ Se imposti il parametro su un valore troppo basso, il processo di vacuum potrebbe dover eseguire la scansione della tabella più volte per completare il lavoro. Queste scansioni multiple possono avere un impatto negativo sulle prestazioni Per le istanze più grandi, impostare `maintenance_work_mem` o `autovacuum_work_mem` su almeno 1 GB può migliorare le prestazioni delle tabelle di vacuum con un numero elevato di tuple morte. Tuttavia, nelle versioni 16 e precedenti di PostgreSQL, l’utilizzo della memoria di vacuum è limitato a 1 GB, il che è sufficiente per elaborare circa 179 milioni di tuple morte in un unico passaggio. Se una tabella ha una quantità superiore di tuple morte, il vacuum dovrà effettuare più passaggi tra gli indici della tabella, facendo aumentare notevolmente il tempo necessario. A partire dalla versione 17 di PostgreSQL, non esiste un limite di 1 GB e la funzionalità di autovacuum può elaborare più di 179 milioni di tuple utilizzando strutture radice.
Un identificatore di tuple ha dimensioni di 6 byte. Per stimare la memoria necessaria per il processo di vacuum di un indice di una tabella, esegui una query `pg_stat_all_tables.n_dead_tup` per trovare il numero di tuple morte, quindi moltiplica questo numero per 6 per determinare la memoria richiesta per svuotare l’indice in un unico passaggio. Puoi utilizzare la seguente query.
```
SELECT
relname AS table_name,
n_dead_tup,
pg_size_pretty(n_dead_tup * 6) AS estimated_memory
FROM
pg_stat_all_tables
WHERE
relname = 'name_of_the_table';
```
+ Il parametro `autovacuum_work_mem` funziona insieme al parametro `autovacuum_max_workers`. Ogni nodo worker tra `autovacuum_max_workers` può utilizzare la memoria allocata. Se si dispone di molte tabelle di piccole dimensioni, assegna più `autovacuum_max_workers` e meno `autovacuum_work_mem`. Se disponi di tabelle di grandi dimensioni (ad esempio, dimensioni superiori a 100 GB), alloca più memoria e meno processi worker. Si deve avere abbastanza memoria allocata affinché si abbia esito positivo sulle tabelle più grandi. Quindi assicurati che la combinazione di processi worker e memoria sia uguale alla memoria totale che desideri allocare.
## Riduzione della probabilità che si verifichi il wraparound dell’ID delle transazioni
In alcuni casi, le impostazioni del gruppo di parametri correlate all'autovacuum potrebbero non essere abbastanza aggressive da prevenire il wraparound dell'ID delle transazioni. Per risolvere questo problema, RDS per PostgreSQL offre un meccanismo che adatta automaticamente i valori del parametro di autovacuum. *Ottimizzazione adattiva del parametro di autovacuum* è una funzionalità di RDS per PostgreSQL. Una spiegazione dettagliata di [Wraparound della transazione](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) si trova nella documentazione di PostgreSQL.
La regolazione adattiva del parametro di autovacuum è attivata per impostazione predefinita per le istanze RDS per PostgreSQL con il parametro dinamico `rds.adaptive_autovacuum` impostato su ON. Si consiglia di tenere questa opzione attivata. Tuttavia, per disattivare l'ottimizzazione adattiva del parametro di autovacuum, impostare il parametro `rds.adaptive_autovacuum` su 0 o OFF.
Il wraparound degli ID di transazione è ancora possibile quando Amazon RDS Amazon RDS regola i parametri di autovacuum. Ti invitiamo a implementare un CloudWatch allarme Amazon per il wraparound degli ID delle transazioni. Per ulteriori informazioni, consulta il post [Implementazione di un sistema di avviso rapido per il wraparound degli ID delle transazioni in RDS per PostgreSQL](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) sul blog del database. AWS
Con l'ottimizzazione adattiva dei parametri dell'autovacuum attivata, Amazon RDS inizia a regolare i parametri dell'autovacuum quando la CloudWatch metrica `MaximumUsedTransactionIDs` raggiunge il valore del parametro o 500.000.000, a seconda di quale sia il maggiore. `autovacuum_freeze_max_age`
Amazon RDS continua ad adattare i parametri per l’autovacuum se una tabella continua a tendere verso i wraparound dell’ID della transazione. Ognuno di questi aggiustamenti dedica più risorse all’autovacuum per evitare il wraparound. Amazon RDS aggiorna i seguenti parametri correlati all’autovacuum:
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
+ [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-AUTOVACUUM-WORK-MEM)
+ [autovacuum\$1naptime](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-NAPTIME)
RDS modifica questi parametri solo se il nuovo valore rende l’autovacuum più aggressivo. I parametri vengono modificati nella memoria sull’istanza database. I valori nel gruppo di parametri non vengono modificati. Per visualizzare le impostazioni in memoria correnti, utilizzare il comando SQL PostgreSQL [SHOW](https://www.postgresql.org/docs/current/sql-show.html).
Quando Amazon RDS modifica uno qualsiasi dei parametri autovacuum, genera un evento per l’istanza database interessata. Questo evento è visibile su Console di gestione AWS e tramite l'API Amazon RDS. Dopo che la `MaximumUsedTransactionIDs` CloudWatch metrica è tornata al di sotto della soglia, Amazon RDS ripristina i parametri relativi all'autovacuum in memoria ai valori specificati nel gruppo di parametri. Quindi genera un altro evento corrispondente a questa modifica.
# Determinare se le tabelle nel database devono essere sottoposte a vacuum
La seguente query può essere utilizzata per mostrare il numero di transazioni sbloccate in un database. La `datfrozenxid` colonna della `pg_database` riga di un database è un limite inferiore della normale transazione che IDs appare in quel database. Questa colonna è il minimo dei valori `relfrozenxid` per tabella all’interno del database.
```
SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;
```
Ad esempio, i risultati dell'esecuzione della query precedente potrebbero essere i seguenti.
```
datname | age
mydb | 1771757888
template0 | 1721757888
template1 | 1721757888
rdsadmin | 1694008527
postgres | 1693881061
(5 rows)
```
Quando l'età di un database raggiunge i 2 miliardi di transazioni IDs, si verifica l'aggiustamento dell'ID della transazione (XID) e il database diventa di sola lettura. Puoi utilizzare questa query per produrre un parametro ed eseguirla alcune volte al giorno. Per impostazione predefinita, l'autovacuum è impostato per mantenere l'età delle transazioni a non più di 200,000,000 ([https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)).
Un esempio di strategia di monitoraggio potrebbe avere questo aspetto:
+ Impostare il valore `autovacuum_freeze_max_age` su 200 milioni di transazioni.
+ Se una tabella raggiunge 500 milioni di transazioni sbloccate, viene attivato un allarme a bassa gravità. Questo non è un valore irragionevole, ma può indicare che l'autovacuum non riesce a mantenere il passo.
+ Se una tabella invecchia a un miliardo, questo dovrebbe essere trattato come un allarme per cui intervenire. In generale, si desidera mantenere le età più vicine a `autovacuum_freeze_max_age` per motivi di prestazioni. Si consiglia di investigare utilizzando le raccomandazioni che seguono.
+ Se una tabella raggiunge 1,5 milioni di transazioni senza vacuum, viene attivato un allarme a gravità elevata. A seconda della velocità con cui il database utilizza la transazione IDs, questo allarme può indicare che il sistema sta per scadere il tempo necessario per eseguire l'autovacuum. In questo caso, consigliamo di risolvere il problema immediatamente.
Se una tabella superando costantemente queste soglie, modifica ulteriormente i parametri dell'autovacuum. Per impostazione predefinita, l’utilizzo manuale di VACUUM (che ha disabilitato i ritardi basati sui costi) è più aggressivo dell'autovacuum predefinito, ma è anche più intrusivo per il sistema nel suo complesso.
Consigliamo quanto segue:
+ Attiva un meccanismo di monitoraggio in modo da essere consapevole dell'età delle transazioni più vecchie.
Per informazioni sulla creazione di un processo che ti avvisa in merito al wraparound degli ID delle transazioni, consulta il post del AWS Database Blog [Implementa an early warning system for Transaction ID wraparound in Amazon RDS for](https://aws.amazon.com/blogs/database/implement-an-early-warning-system-for-transaction-id-wraparound-in-amazon-rds-for-postgresql/) PostgreSQL.
+ Per le tabelle più occupate, eseguire regolarmente un congelamento manuale del vacuum durante una finestra di manutenzione, oltre a fare affidamento sull'autovacuum. Per informazioni sull'esecuzione di un congelamento manuale del vacuum, consulta [Esecuzione di un congelamento manuale del vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
# Determinare quali tabelle sono attualmente idonee per l'Autovacuum
Spesso, una o due tabelle hanno bisogno del vacuum. Le tabelle il cui valore `relfrozenxid` sia maggiore del numero di transazioni in `autovacuum_freeze_max_age` sono sempre destinate all’autovacuum. Altrimenti, se il numero di tuple reso obsoleto dall'ultimo VACUUM supera la soglia del vacuum, la tabella viene sottoposta a vacuum.
La [autovacuum threshold (soglia di autovacuum)](https://www.postgresql.org/docs/current/static/routine-vacuuming.html#AUTOVACUUM) viene definita come:
```
Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples
```
dove `vacuum base threshold` è `autovacuum_vacuum_threshold`, `vacuum scale factor` è `autovacuum_vacuum_scale_factor` e `number of tuples` è `pg_class.reltuples`.
Mentre sei connesso al database, esegui la seguente query per visualizzare un elenco di tabelle che Autovacuum vede come idonee per il vacuuming.
```
WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'),
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) *
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;
```
# Determinare se l'Auotvacuum è attualmente in esecuzione e per quanto tempo
Se è necessario procedere manualmente con il vacuum in una tabella, devi determinare se l'autovacuum è attualmente in esecuzione. In tal caso, potrebbe essere necessario regolare i parametri per farlo eseguire in modo più efficiente oppure disattivare l'autovacuum temporaneamente in modo da poter eseguire manualmente il VACUUM.
Utilizzare la seguente query per determinare se l'autovacuum è in esecuzione, da quanto tempo è in esecuzione e se è in attesa su un'altra sessione.
```
SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity
WHERE upper(query) LIKE '%VACUUM%'
ORDER BY xact_start;
```
Dopo l'esecuzione della query, si dovrebbe visualizzare un output simile a quello riportato di seguito.
```
datname | usename | pid | state | wait_event | xact_runtime | query
--------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
mydb | rdsadmin | 16473 | active | | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
mydb | rdsadmin | 22553 | active | | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
mydb | rdsadmin | 41909 | active | | 3 days 02:43:54.203349 | autovacuum: VACUUM ANALYZE public.mytable3
mydb | rdsadmin | 618 | active | | 00:00:00 | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
| | | | | | FROM pg_stat_activity +
| | | | | | WHERE query like '%VACUUM%' +
| | | | | | ORDER BY xact_start; +
```
Diversi problemi possono provocare sessioni di autovacuum di lunga esecuzione (che durano più giorni). Il problema più comune è che il valore del parametro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) è impostato come troppo basso per la dimensione della tabella o la frequenza degli aggiornamenti.
Consigliamo di utilizzare la seguente formula per impostare il valore del parametro `maintenance_work_mem`.
```
GREATEST({DBInstanceClassMemory/63963136*1024},65536)
```
Le sessioni autovacuum a breve esecuzioni possono anche indicare dei problemi:
+ Può indicare che non ci sono abbastanza `autovacuum_max_workers` per il carico di lavoro. In questo caso, sarà necessario indicare il numero di lavoratori.
+ Può indicare che esiste un danneggiamento dell'indice (l'autovacuum si blocca e si riavvia sulla stessa relazione ma non ci sono progressi). In questo caso, esegui un `vacuum freeze verbose table` manuale per vedere la causa esatta.
# Esecuzione di un congelamento manuale del vacuum
Si potrebbe voler eseguire un vacuum manuale su una tabella che ha già un processo di vacuum in esecuzione. Ciò è utile se hai identificato una tabella con un'età che si avvicina a 2 miliardi (o al di sopra di qualsiasi soglia monitorata).
I seguenti passaggi sono delle linea guida, con diverse varianti del processo. Ad esempio, durante la verifica, supporre che il valore del parametro [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) sia stato impostato come troppo piccolo e che sia necessario agire immediatamente su una tabella. Tuttavia, probabilmente al momento non desideri che l’istanza non venga recapitata. Utilizzando le query delle sezioni precedenti, si determina quale tabella rappresenta il problema e si nota una sessione autovacuum a lunga esecuzione. Si sa che è necessario cambiare l'impostazione del parametro `maintenance_work_mem`, ma è necessario anche agire immediatamente ed eseguire il vacuum della tabella in questione. La procedura seguente mostra cosa fare in questa situazione.
**Per eseguire manualmente un congelamento del vacuum**
1. Aprire due sessioni nel database che contiene la tabella che si desidera sottoporre a vacuum. Per la seconda sessione, utilizzare "screen" o un'altra utility che mantiene la sessione se la connessione viene interrotta.
1. Nella sessione uno, ottieni l’ID di processo (PID) della sessione di autovacuum in esecuzione sulla tabella.
Eseguire la query seguente per ottenere il PID della sessione di autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY
xact_start;
```
1. Nella sessione due, calcoli la quantità di memoria necessaria per questa operazione. In questo esempio, stabiliamo che è possibile permettersi di utilizzare fino a 2 GB di memoria per questa operazione, pertanto abbiamo impostato [https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) per la sessione corrente su 2 GB.
```
SET maintenance_work_mem='2 GB';
SET
```
1. Nella sessione 2, inviare un comando `vacuum freeze verbose` per la tabella. L'impostazione di verbose è utile perché, anche se al momento non vi è alcun rapporto sullo stato di avanzamento in PostgreSQL, è possibile visualizzare l'attività.
```
\timing on
Timing is on.
vacuum freeze verbose pgbench_branches;
```
```
INFO: vacuuming "public.pgbench_branches"
INFO: index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pgbench_branches": found 0 removable, 50 nonremovable row versions
in 43 out of 43 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 9347 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
Time: 2.765 ms
```
1. Nella sessione uno, se il processo di autovacuum bloccava la sessione di vacuum, `pg_stat_activity` mostra che l’attesa è `T` per la sessione di vacuum. In questo caso, termina il processo di autovacuum come segue.
```
SELECT pg_terminate_backend('the_pid');
```
**Nota**
Alcune versioni precedenti di Amazon RDS non possono terminare un processo di autovacuum utilizzando il comando precedente e viene generato il seguente errore: `ERROR: 42501: must be a superuser to terminate superuser process LOCATION: pg_terminate_backend, signalfuncs.c:227`.
In questo momento, inizia la sessione. La funzionalità di autovacuum si riavvia immediatamente poiché questa tabella ha probabilmente la posizione superiore nella lista di lavoro.
1. Avvia il comando `vacuum freeze verbose` nella sessione due, quindi termina il processo di autovacuum nella sessione uno.
# Indicizzare di nuovo una tabella quando l'autovacuum è in esecuzione
Se un indice diventa corrotto, l'autovacuum continua a elaborare la tabella e avrà esito negativo. Setenti di eseguire un vacuum manuale in questa situazione, riceverai un messaggio di errore come il seguente.
```
postgres=> vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected
zero page at block 30521
HINT: Please REINDEX it.
```
Quando l'indice è corrotto e l'autovacuum sta tentando l'esecuzione sulla tabella, ci sarà una contesa con una sessione di autovacuum già in esecuzione. Quando si immette un comando [REINDEX](https://www.postgresql.org/docs/current/static/sql-reindex.html), si richiede un blocco esclusivo sulla tabella. Le operazioni in scrittura sono bloccate e anche quelle in lettura che utilizzano l’indice specifico.
**Per indicizzare di nuovo una tabella quando l'autovacuum è in esecuzione sulla tabella**
1. Apri due sessioni nel database che contiene la tabella da sottoporre a vacuum. Per la seconda sessione, utilizzare "screen" o un'altra utility che mantiene la sessione se la connessione viene interrotta.
1. Nella sessione numero uno, ottenere il PID della sessione di autovacuum in esecuzione sulla tabella.
Eseguire la query seguente per ottenere il PID della sessione di autovacuum.
```
SELECT datname, usename, pid, current_timestamp - xact_start
AS xact_runtime, query
FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY
xact_start;
```
1. Nella sessione due, rilasciare il comando di reindicizzazione.
```
\timing on
Timing is on.
reindex index pgbench_branches_test_index;
REINDEX
Time: 9.966 ms
```
1. Nella sessione uno, se l'autovacuum bloccava il processo, in `pg_stat_activity` vedi che l'attesa è "T" per la sessione di vacuum. In questo caso, termina il processo di autovacuum.
```
SELECT pg_terminate_backend('the_pid');
```
In questo momento, inizia la sessione. È importante notare che l'autovacuum si riavvia immediatamente poiché questa tabella è probabilmente la più alta nella lista di lavori.
1. Avvia il comando nella sessione due, quindi termina il processo di autovacuum nella sessione 1.
# Gestione di autovacuum con indici di grandi dimensioni
Come parte del funzionamento, *autovacuum* esegue diverse [fasi di vacuum](https://www.postgresql.org/docs/current/progress-reporting.html#VACUUM-PHASES) mentre viene eseguito su una tabella. Prima che la tabella venga pulita, tutti i suoi indici vengono prima sottoposti al vacuum. Quando si rimuovono più indici di grandi dimensioni, questa fase richiede una notevole quantità di tempo e risorse. Pertanto, come best practice, assicurati di controllare il numero di indici in una tabella ed eliminare gli indici non utilizzati.
Per questo processo, controlla innanzitutto la dimensione complessiva degli indici. Quindi, determina se ci sono indici potenzialmente inutilizzati da rimuovere come mostrato negli esempi seguenti.
**Per verificare la dimensione della tabella e dei relativi indici**
```
postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)
```
```
postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)
```
In questo esempio, la dimensione degli indici è maggiore della tabella. Questa differenza può causare problemi di prestazioni perché gli indici sono aumentati in dimensioni o inutilizzati, il che influisce sull'autovacuum e sulle operazioni di inserimento.
**Per verificare la presenza di indici non utilizzati**
Utilizzando la visualizzazione [https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW), è possibile verificare la frequenza con cui viene utilizzato un indice con la colonna `idx_scan`. Nell'esempio seguente, gli indici non utilizzati hanno `idx_scan` con il valore `0`.
```
postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
relid | indexrelid | schemaname | relname | indexrelname | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433 | 16454 | public | pgbench_accounts | index_f | 6 | 6 | 0
16433 | 16450 | public | pgbench_accounts | index_b | 3 | 199999 | 0
16433 | 16447 | public | pgbench_accounts | pgbench_accounts_pkey | 0 | 0 | 0
16433 | 16452 | public | pgbench_accounts | index_d | 0 | 0 | 0
16433 | 16453 | public | pgbench_accounts | index_e | 0 | 0 | 0
16433 | 16451 | public | pgbench_accounts | index_c | 0 | 0 | 0
16433 | 16449 | public | pgbench_accounts | index_a | 0 | 0 | 0
(7 rows)
```
```
postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
schemaname | relname | indexrelname | idx_scan
------------+------------------+-----------------------+----------
public | pgbench_accounts | index_f | 6
public | pgbench_accounts | index_b | 3
public | pgbench_accounts | pgbench_accounts_pkey | 0
public | pgbench_accounts | index_d | 0
public | pgbench_accounts | index_e | 0
public | pgbench_accounts | index_c | 0
public | pgbench_accounts | index_a | 0
(7 rows)
```
**Nota**
Queste statistiche sono incrementali dal momento in cui vengono ripristinate. Supponi di avere un indice utilizzato solo alla fine di un trimestre lavorativo o solo per un report specifico. È possibile che questo indice non sia stato utilizzato da quando le statistiche sono state ripristinate. Per ulteriori informazioni, consulta [Funzioni statistiche](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-STATS-FUNCTIONS). Gli indici utilizzati per garantire l'univocità non vengono sottoposti ad analisi e non devono essere identificati come indici non utilizzati. Per identificare gli indici non utilizzati, è necessario avere una conoscenza approfondita dell'applicazione e delle relative query.
Per verificare quando le statistiche sono state ripristinate l'ultima volta per un database, usa [ 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)
```
postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
datname | stats_reset
----------+-------------------------------
postgres | 2022-11-17 08:58:11.427224+00
(1 row)
```
## Vacuum di una tabella il più rapidamente possibile
**RDS per PostgreSQL 12 e versioni successive**
Se sono presenti troppi indici in una tabella di grandi dimensioni, l'istanza database potrebbe essere vicina al wraparound dell'ID di transazione (XID), ovvero quando il contatore XID arriva a zero. Se non controllata, questa situazione potrebbe causare la perdita di dati. Tuttavia, è possibile eseguire rapidamente il vacuum della tabella senza ripulire gli indici. In RDS per PostgreSQL 12 e versioni successive, puoi usare VACUUM con la clausola [https://www.postgresql.org/docs/current/sql-vacuum.html](https://www.postgresql.org/docs/current/sql-vacuum.html).
```
postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
```
Se è già in esecuzione una sessione di autovacuum, è necessario interromperla per iniziare il VACUUM manuale. Per informazioni sull'esecuzione di un congelamento manuale del vacuum, consulta [Esecuzione di un congelamento manuale del vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.md).
**Nota**
Se si evita di eseguire regolarmente la pulizia, si verifica il bloat dell’indice, con ripercussioni sulle prestazioni della scansione. L’indice mantiene le righe morte e la tabella mantiene i puntatori delle linee morte. Di conseguenza, `pg_stat_all_tables.n_dead_tup` aumenta finché non viene eseguito un processo di autovacuum o un VACUUM manuale con pulizia dell’indice. Come best practice, utilizza questa procedura solo per evitare il wraparound degli ID di transazione.
**RDS per PostgreSQL 11 e versioni precedenti**
Tuttavia, in RDS per PostgreSQL 11 e versioni precedenti, l'unico modo per eseguire il vacuum più rapidamente è riducendo il numero di indici su una tabella. L'eliminazione di un indice può influire sui piani di query. Ti consigliamo di eliminare prima gli indici inutilizzati, quindi quelli che hanno il wraparound XID molto vicino. Una volta completato il processo di vacuum, è possibile ricreare questi indici.
# Altri parametri che influenzano l'autovacuum
La query seguente mostra i valori di alcuni dei parametri che influenzano direttamente l'autovacuum e il suo comportamento. I [parametri di autovacuum](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html) vengono descritti in forma completa nella documentazione di PostgreSQL.
```
SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');
```
Mentre questi riguardano tutti l'autovacuum, alcuni dei più importanti sono:
+ [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#GUC-MAINTENANCE_WORK_MEM)
+ [autovacuum\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-FREEZE-MAX-AGE)
+ [autovacuum\$1max\$1workers](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MAX-WORKERS)
+ [autovacuum\$1vacuum\$1cost\$1delay](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-DELAY)
+ [ autovacuum\$1vacuum\$1cost\$1limit](https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-COST-LIMIT)
# Impostazione dei parametri di autovacuum a livello tabella
Puoi impostare i [parametri di archiviazione](https://www.postgresql.org/docs/current/static/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS) correlati all'autovacuum a livello di tabella, che può essere meglio di alterare il comportamento dell'intero database. Per le tabelle di grandi dimensioni, potrebbe essere necessario regolare impostazioni aggressive e si potrebbe non desiderare di eseguire l'autovacuum in questo modo per tutte le tabelle.
La query seguente mostra quali tabelle attualmente dispongono di opzioni a livello di tabella.
```
SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;
```
Un esempio in cui ciò potrebbe essere utile è per tabelle che sono molto più grandi rispetto al resto delle tabelle. Supponi di disporre di una tabella da 300 GB e di altre 30 tabelle da meno di un GB. Se disponi di una tabella da 300 GB e di altre 30 tabelle da meno di 1 GB, puoi impostare alcuni parametri specifici per la tabella di grandi dimensioni in modo da non alterare il comportamento dell'intero sistema.
```
ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);
```
In questo modo si disattiva il ritardo dell'autovacuum basato sul costo per questa tabella a spese di un maggiore utilizzo delle risorse sul sistema. Normalmente, l'autovacuum si ferma per `autovacuum_vacuum_cost_delay` ogni volta che viene raggiunto `autovacuum_cost_limit`. Per ulteriori dettagli, consulta la documentazione di PostegreSQL relativa al [vacuuming basato sul costo](https://www.postgresql.org/docs/current/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-VACUUM-COST).
# Registrazione delle attività di autovacuum e vacuum
Le informazioni sulle attività dell'autovacuum vengono inviate a `postgresql.log` in base al livello specificato nel parametro `rds.force_autovacuum_logging_level`. Di seguito sono riportati i valori consentiti per questo parametro e le versioni di PostgreSQL per le quali tale valore è l'impostazione predefinita:
+ `disabled` (PostgreSQL 10, PostgreSQL 9.6)
+ `debug5`, `debug4`, `debug3`, `debug2`, `debug1`
+ `info` (PostgreSQL 12, PostgreSQL 11)
+ `notice`
+ `warning` (PostgreSQL 13 e versioni successive)
+ `error`, log, `fatal`, `panic`
`rds.force_autovacuum_logging_level` funziona con il parametro `log_autovacuum_min_duration`. Il valore del parametro `log_autovacuum_min_duration` è la soglia (in millisecondi) al di sopra della quale vengono registrate le azioni dell'autovacuum. Un ambiente di `-1` non registra nulla, mentre un'impostazione di 0 registra tutte le azioni. Come con `rds.force_autovacuum_logging_level`, i valori predefiniti per `log_autovacuum_min_duration` dipendono dalla versione, come segue:
+ `10000 ms` – PostgreSQL 14, PostgreSQL 13, PostgreSQL 12 e PostgreSQL 11
+ `(empty)` – Nessun valore predefinito per PostgreSQL 10 e PostgreSQL 9.6
Consigliamo di impostare `rds.force_autovacuum_logging_level` su `WARNING`. Consigliamo anche di impostare `log_autovacuum_min_duration` su un valore compreso tra 1000 e 5000. Un'impostazione di 5000 registri di attività che richiede più di 5000 millisecondi. Qualsiasi impostazione diversa da -1 registra anche i messaggi se l'azione dell'autovacuum viene ignorata a causa di un blocco in conflitto o di relazioni interrotte simultaneamente. Per ulteriori informazioni, consulta la pagina relativa al [vacuum automatico](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html) nella documentazione di PostgreSQL.
Per risolvere i problemi, è possibile modificare il parametro `rds.force_autovacuum_logging_level` in uno dei livelli di debug, da `debug1` fino a `debug5` per le informazioni più dettagliate. Si consiglia di utilizzare le impostazioni di debug per brevi periodi di tempo e solo per la risoluzione dei problemi. Per ulteriori informazioni, consulta [Quando registrare](https://www.postgresql.org/docs/current/static/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN) nella documentazione di PostgreSQL.
**Nota**
PostgreSQL consente all'account `rds_superuser` di visualizzare le sessioni di autovacuum in `pg_stat_activity`. Ad esempio, è possibile identificare e terminare una sessione di autovacuum che blocca l'esecuzione di un comando o l'esecuzione più lenta di un comando vacuum emesso manualmente.
# Comprensione del comportamento della funzionalità di autovacuum con database non validi
Viene introdotto un nuovo valore `-2` nella colonna `datconnlimit` del catalogo `pg_database` per indicare come non validi i database che sono stati interrotti durante l’operazione DROP DATABASE.
Questo nuovo valore è disponibile nelle seguenti versioni di RDS per PostgreSQL:
+ 15.4 e tutte le versioni successive
+ 14.9 e versioni successive
+ 13.12 e versioni successive
+ 12.16 e versioni successive
+ 11.21 e versioni successive
I database non validi non influiscono sulla capacità della funzionalità di autovacuum di bloccare le funzionalità dei database validi. La funzionalità autovacuum ignora i database non validi. Di conseguenza, le normali operazioni di vacuum continueranno a funzionare correttamente ed efficacemente per tutti i database validi nell’ambiente PostgreSQL.
**Topics**
+ [Monitoraggio dell’ID di transazione](#appendix.postgresql.commondbatasks.autovacuum.monitorxid)
+ [Modifica della query di monitoraggio](#appendix.postgresql.commondbatasks.autovacuum.monitoradjust)
+ [Risoluzione dei problemi relativi a database non validi](#appendix.postgresql.commondbatasks.autovacuum.connissue)
## Monitoraggio dell’ID di transazione
La funzione `age(datfrozenxid)` viene comunemente utilizzata per monitorare l’età degli ID di transazione (XID) dei database per evitare che si verifichi il wraparound degli ID.
Poiché i database non validi vengono esclusi dall’autovacuum, il relativo contatore dell’ID di transazione (XID) può raggiungere il valore massimo di `2 billion`, eseguire il wraparound a `- 2 billion` e continuare questo ciclo all’infinito. Una tipica query per monitorare il wraparound degli ID di transazione potrebbe essere simile a:
```
SELECT max(age(datfrozenxid)) FROM pg_database;
```
Tuttavia, con l’introduzione del valore -2 per `datconnlimit`, i database non validi possono alterare i risultati di questa query. Poiché questi database non sono validi e non devono essere sottoposti a regolari controlli di manutenzione, possono causare falsi positivi, inducendo a credere che il valore `age(datfrozenxid)` sia superiore a quello reale.
## Modifica della query di monitoraggio
Per garantire l’accuratezza del monitoraggio, è necessario modificare la query di monitoraggio per escludere i database non validi. Segui questa query consigliata:
```
SELECT
max(age(datfrozenxid))
FROM
pg_database
WHERE
datconnlimit <> -2;
```
Questa query garantisce che nel calcolo di `age(datfrozenxid)` vengano presi in considerazione solo i database validi, fornendo un riflesso fedele dell’età degli ID di transazione nell’ambiente PostgreSQL.
## Risoluzione dei problemi relativi a database non validi
Quando tenti di connetterti a un database non valido, potrebbe essere visualizzato un messaggio di errore simile al seguente:
```
postgres=> \c db1
connection to server at "mydb.xxxxxxxxxx.us-west-2.rds.amazonaws.com" (xx.xx.xx.xxx), port xxxx failed: FATAL: cannot connect to invalid database "db1"
HINT: Use DROP DATABASE to drop invalid databases.
Previous connection kept
```
Inoltre, se il parametro `log_min_messages` è impostato su `DEBUG2` o successivo, è possibile che vengano visualizzate le seguenti voci di log che indicano che il processo autovacuum sta ignorando il database non valido:
```
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db6"
2024-07-30 05:59:00 UTC::@:[32000]:DEBUG: autovacuum: skipping invalid database "db1"
```
Per risolvere il problema, segui il valore `HINT` fornito durante il tentativo di connessione. Connettiti a qualsiasi database valido utilizzando l’account master RDS o un account di database con il ruolo `rds_superuser` ed elimina i database non validi.
```
SELECT
'DROP DATABASE ' || quote_ident(datname) || ';'
FROM
pg_database
WHERE
datconnlimit = -2 \gexec
```
# Identificazione e risoluzione dei blocchi per i processi di vacuum aggressivi in RDS per PostgreSQL
In PostgreSQL, il processo di vacuum è fondamentale per garantire l’integrità del database poiché consente di recuperare spazio di archiviazione e previene eventuali problemi di [wraparound degli ID transazione](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND). Tuttavia, in alcune situazioni è possibile che il processo di vacuum non funzioni come desiderato; le conseguenze possono essere: riduzione delle prestazioni, bloat dello spazio di archiviazione e impatto sulla disponibilità dell’istanza database in uso a causa del wraparound degli ID transazione. Pertanto, l’identificazione e la risoluzione dei suddetti problemi sono essenziali per garantire prestazioni e disponibilità ottimali del database. Per ulteriori informazioni sul processo di autovacuum, consulta [Understanding autovacuum in Amazon RDS for PostgreSQL environments](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
La funzione `postgres_get_av_diag()` aiuta a identificare i problemi che impediscono o ritardano l’avanzamento dei processi di vacuum aggressivi. Vengono forniti dei suggerimenti, che possono includere comandi per risolvere il problema laddove esso sia identificabile o indicazioni per ulteriori operazioni di diagnosi laddove il problema non sia identificabile. I [vacuobloccanti aggressivi vengono segnalati quando l'età supera la soglia di autovuoto adattivo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) di RDS di 500 milioni di transazioni. IDs
**Qual è l’età dell’ID transazione?**
La `age()` funzione per la transazione IDs calcola il numero di transazioni avvenute dal più vecchio ID di transazione non bloccato per un database () o una tabella (). `pg_database.datfrozenxid` `pg_class.relfrozenxid` Questo valore indica l’attività del database dall’ultima operazione di vacuum aggressiva ed evidenzia il probabile carico di lavoro per i successivi processi VACUUM.
**In cosa consiste un processo di vacuum aggressivo?**
Un'operazione VACUUM aggressiva esegue una scansione completa di tutte le pagine all'interno di una tabella, comprese quelle normalmente saltate durante la normale procedura. VACUUMs [Questa scansione approfondita mira a «congelare» le transazioni che IDs si avvicinano alla loro età massima, prevenendo efficacemente una situazione nota come transazione ID wraparound.](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND)
Affinché `postgres_get_av_diag()` li segnali, gli elementi bloccanti devono avere un’età di almeno 500 milioni di transazioni.
**Topics**
+ [Installazione di strumenti di diagnostica e monitoraggio dei processi di autovacuum in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md)
+ [Funzioni di postgres\$1get\$1av\$1diag() in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Functions.md)
+ [Risoluzione dei blocchi identificabili per i processi di vacuum in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md)
+ [Risoluzione dei blocchi non identificabili per i processi di vacuum in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Unidentifiable_blockers.md)
+ [Risoluzione dei problemi relativi alle prestazioni di vacuum in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md)
+ [Spiegazione dei messaggi NOTICE in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md)
# Installazione di strumenti di diagnostica e monitoraggio dei processi di autovacuum in RDS per PostgreSQL
La funzione `postgres_get_av_diag()` è attualmente disponibile nelle seguenti versioni di RDS per PostgreSQL:
+ 17.2 o versioni successive alla 17
+ 16.7 e versioni successive alla 16
+ 15.11 o versioni successive alla 15
+ 14.16 o versioni successive alla 14
+ 13.19 o versioni successive alla 13
Per utilizzare `postgres_get_av_diag()`, crea l’estensione `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools ;
CREATE EXTENSION
```
Verifica che l’estensione sia stata installata.
```
postgres=> \dx rds_tools
List of installed extensions
Name | Version | Schema | Description
----------+---------+-----------+----------------------------------------------------------
rds_tools | 1.8 | rds_tools | miscellaneous administrative functions for RDS PostgreSQL
1 row
```
Verifica che la funzione sia stata creata.
```
postgres=> SELECT
proname function_name,
pronamespace::regnamespace function_schema,
proowner::regrole function_owner
FROM
pg_proc
WHERE
proname = 'postgres_get_av_diag';
function_name | function_schema | function_owner
----------------------+-----------------+----------------
postgres_get_av_diag | rds_tools | rds_superuser
(1 row)
```
# Funzioni di postgres\$1get\$1av\$1diag() in RDS per PostgreSQL
La funzione `postgres_get_av_diag()` recupera informazioni diagnostiche sui processi di autovacuum che si bloccano o sono in ritardo in un database RDS per PostgreSQL. Per ottenere risultati accurati, la query deve essere eseguita nel database con l’ID transazione meno recente. Per ulteriori informazioni sull’utilizzo del database con l’ID transazione meno recente, consulta [Mancata connessione al database con l’età dell’ID transazione meno recente](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
```
SELECT
blocker,
DATABASE,
blocker_identifier,
wait_event,
TO_CHAR(autovacuum_lagging_by, 'FM9,999,999,999') AS autovacuum_lagging_by,
suggestion,
suggested_action
FROM (
SELECT
*
FROM
rds_tools.postgres_get_av_diag ()
ORDER BY
autovacuum_lagging_by DESC) q;
```
La funzione `postgres_get_av_diag()` restituisce una tabella con le seguenti informazioni:
**elemento bloccante**
Specifica la categoria di attività del database che blocca il processo di vacuum.
+ [Istruzione attiva](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Inattivo in transazione](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transazione preparata](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot di replica logica](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Replica di lettura con slot di replica fisica](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Replica di lettura con replica in streaming](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabelle temporanee](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Identifiableblockers.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
**database**
Specifica il nome del database, ove pertinente e supportato. Si tratta del database in cui l’attività è in corso e che blocca o bloccherà il processo di autovacuum. È il database a cui devi connetterti e sul quale devi agire.
**blocker\$1identifier**
Specifica l’identificatore dell’attività che blocca o bloccherà il processo di autovacuum. L’identificatore può essere un ID processo insieme a un’istruzione SQL, una transazione preparata, un indirizzo IP di una replica di lettura e il nome dello slot di replica (logica o fisica).
**wait\$1event**
Specifica l’[evento di attesa](PostgreSQL.Tuning.md) della sessione di blocco ed è applicabile ai seguenti elementi bloccanti:
+ Istruzione attiva
+ Inattivo in transazione
**autovacum\$1lagging\$1by**
Specifica il numero di transazioni di cui il processo di autovacuum è in ritardo nel lavoro di backlog per categoria.
**suggestion**
Specifica i suggerimenti per risolvere il blocco. Queste istruzioni includono il nome del database in cui esistono l’attività (ove applicabile), l’ID processo (PID) della sessione (ove applicabile) e l’azione da intraprendere.
**suggested\$1action**
Suggerisci l’azione che è necessario intraprendere per risolvere il blocco.
# Risoluzione dei blocchi identificabili per i processi di vacuum in RDS per PostgreSQL
La funzionalità di autovacuum esegue processi di vacuum aggressivi e porta l’età degli ID transazione al di sotto della soglia specificata dal parametro `autovacuum_freeze_max_age` dell’istanza RDS in uso. Puoi tenere traccia del valore di età utilizzando la metrica `MaximumUsedTransactionIDs` di Amazon CloudWatch.
Per trovare l’impostazione di `autovacuum_freeze_max_age` (che ha un valore predefinito di 200 milioni di ID transazione) per la tua istanza Amazon RDS, puoi utilizzare la seguente query:
```
SELECT
TO_CHAR(setting::bigint, 'FM9,999,999,999') autovacuum_freeze_max_age
FROM
pg_settings
WHERE
name = 'autovacuum_freeze_max_age';
```
`postgres_get_av_diag()` verifica la presenza di eventuali elementi bloccanti per i processi di vacuum aggressivi solo quando l’età supera la soglia di [autovacuum adattivo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.AdaptiveAutoVacuuming) di Amazon RDS, che corrisponde a 500 milioni di ID transazione. Affinché `postgres_get_av_diag()` li rilevi, gli elementi bloccanti devono avere un’età di almeno 500 milioni di transazioni.
La funzione `postgres_get_av_diag()` identifica i seguenti tipi di elementi bloccanti:
**Topics**
+ [Istruzione attiva](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Active_statement)
+ [Inattivo in transazione](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Idle_in_transaction)
+ [Transazione preparata](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Prepared_transaction)
+ [Slot di replica logica](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Logical_replication_slot)
+ [Repliche di lettura](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Read_replicas)
+ [Tabelle temporanee](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Temporary_tables)
## Istruzione attiva
In PostgreSQL, un’istruzione attiva è un’istruzione SQL attualmente che è in fase di esecuzione da parte del database. Sono incluse query, transazioni o eventuali operazione in corso. Durante il monitoraggio tramite `pg_stat_activity`, la colonna dello stato indica che il processo con il PID corrispondente è attivo.
La funzione `postgres_get_av_diag()` visualizza un output simile a quanto segue quando identifica un’istruzione che è attiva.
```
blocker | Active statement
database | my_database
blocker_identifier | SELECT pg_sleep(20000);
wait_event | Timeout:PgSleep
autovacuum_lagging_by | 568,600,871
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (29621);"}
```
**Azione suggerita**
Seguendo le indicazioni riportate nella colonna `suggestion`, l’utente può connettersi al database in cui è presente l’istruzione attiva e, come specificato nella colonna `suggested_action`, è consigliabile esaminare attentamente l’opzione per terminare la sessione. Se è sicuro eseguire la terminazione, è possibile utilizzare la funzione `pg_terminate_backend()` per terminare la sessione. Questa azione può essere eseguita da un utente amministratore (come l’account principale RDS) o da un utente con il privilegio `pg_terminate_backend()` richiesto.
**avvertimento**
Una sessione terminata annullerà (`ROLLBACK`) le modifiche apportate. A seconda delle esigenze del caso, potresti voler eseguire nuovamente l’istruzione. Tuttavia, si consiglia di eseguire tale operazione solo dopo che il processo di autovacuum ha terminato il processo di vacuum aggressivo.
## Inattivo in transazione
Un’istruzione di inattività in transazione si riferisce a una sessione che ha aperto una transazione esplicita (ad esempio, emettendo un’istruzione `BEGIN`), ha eseguito del lavoro e ora è in attesa che il client passi altro lavoro o segnali la fine della transazione emettendo un’istruzione `COMMIT`, `ROLLBACK` o `END` (che darebbe luogo a un’operazione `COMMIT` implicita).
La funzione `postgres_get_av_diag()` visualizza un output simile a quanto segue quando identifica un’istruzione `idle in transaction` come elemento bloccante.
```
blocker | idle in transaction
database | my_database
blocker_identifier | INSERT INTO tt SELECT * FROM tt;
wait_event | Client:ClientRead
autovacuum_lagging_by | 1,237,201,759
suggestion | Connect to database "my_database", review carefully and you may consider terminating the process using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_terminate_backend (28438);"}
```
**Azione suggerita**
Come indicato nella colonna `suggestion`, è possibile connettersi al database in cui è presente una sessione di inattività in transazione e terminare la sessione utilizzando la funzione `pg_terminate_backend()`. L’utente può essere l’utente amministratore (account principale RDS) o un utente con il privilegio `pg_terminate_backend()`.
**avvertimento**
Una sessione terminata annullerà (`ROLLBACK`) le modifiche apportate. A seconda delle esigenze del caso, potresti voler eseguire nuovamente l’istruzione. Tuttavia, si consiglia di eseguire tale operazione solo dopo che il processo di autovacuum ha terminato il processo di vacuum aggressivo.
## Transazione preparata
PostgreSQL consente le transazioni che fanno parte di una strategia di commit in due fasi, denominate [transazioni preparate](https://www.postgresql.org/docs/current/sql-prepare-transaction.html). Queste vengono abilitate impostando il parametro `max_prepared_transactions` su un valore diverso da zero. Le transazioni preparate sono concepite per garantire che una transazione sia duratura e rimanga disponibile anche dopo crash del database, riavvii o disconnessioni del client. Così come avviene con le transazioni standard, anche le transazioni preparate ricevono in assegnazione un ID transazione e possono influire sul processo di autovacuum. Se lasciato in stato preparato, il processo di autovacuum non può eseguire il blocco e può portare al wraparound degli ID transazione.
Quando le transazioni vengono lasciate in stato preparato indefinitamente senza essere risolte da un gestore di transazioni, diventano transazioni preparate orfane. L’unica soluzione consiste nell’eseguire il commit o il rollback della transazione utilizzando rispettivamente i comandi `COMMIT PREPARED` o `ROLLBACK PREPARED`.
**Nota**
Tieni presente che un backup eseguito durante una transazione preparata conterrà comunque tale transazione dopo il ripristino. Consulta le seguenti informazioni su come individuare e chiudere tali transazioni.
La funzione `postgres_get_av_diag()` visualizza il seguente output quando identifica un elemento bloccante che è una transazione preparata.
```
blocker | Prepared transaction
database | my_database
blocker_identifier | myptx
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database" and consider either COMMIT or ROLLBACK the prepared transaction using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"COMMIT PREPARED 'myptx';",[OR],"ROLLBACK PREPARED 'myptx';"}
```
**Azione suggerita**
Come indicato nella colonna dei suggerimenti, connettiti al database in cui si trova la transazione preparata. In base alla colonna `suggested_action`, valuta attentamente se eseguire un’operazione di `COMMIT` o `ROLLBACK` e poi l’azione appropriata.
Per monitorare le transazioni preparate in generale, PostgreSQL offre una vista in stile catalogo denominata `pg_prepared_xacts`. La seguente query può essere utilizzata per trovare le transazioni preparate.
```
SELECT
gid,
prepared,
owner,
database,
transaction AS oldest_xmin
FROM
pg_prepared_xacts
ORDER BY
age(transaction) DESC;
```
## Slot di replica logica
Lo scopo di uno slot di replica è conservare le modifiche non utilizzate finché non vengono replicate su un server di destinazione. Per ulteriori informazioni, consulta la pagina relativa alla [replica logica](https://www.postgresql.org/docs/current/logical-replication.html) di PostgreSQL.
Esistono due tipi di slot di replica logica.
**Slot di replica logica inattivi**
Quando la replica viene terminata, i log delle transazioni non utilizzati non possono essere rimossi e lo slot di replica diventa inattivo. Gli slot di replica logica inattivi non vengono utilizzati dai nodi subscriber, ma rimangono comunque sul server, il che comporta la conservazione dei file WAL e impedisce la rimozione dei log delle transazioni meno recenti. Ciò può aumentare l’utilizzo del disco e, nello specifico, impedire al processo di autovacuum di eseguire la pulizia delle tabelle interne del catalogo, poiché il sistema deve impedire che le informazioni LSN vengano sovrascritte. Se il problema non viene risolto, possono verificarsi conseguenze come bloat del catalogo, riduzione delle prestazioni, aumento del rischio di wraparound nel processo di vacuum e quindi potenziali tempi di inattività per le transazioni.
**Slot di replica logica attivi ma lenti**
Talvolta la rimozione delle tuple morte del catalogo viene ritardata a causa della riduzione delle prestazioni della replica logica. Questo ritardo nella replica, che rallenta l’aggiornamento di `catalog_xmin`, può causare bloat del catalogo e wraparound nel processo di vacuum.
La funzione `postgres_get_av_diag()` visualizza un output simile a quanto segue quando individua in uno slot di replica logica un elemento bloccante.
```
blocker | Logical replication slot
database | my_database
blocker_identifier | slot1
wait_event | Not applicable
autovacuum_lagging_by | 1,940,103,068
suggestion | Ensure replication is active and resolve any lag for the slot if active. If inactive, consider dropping it using the command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"SELECT pg_drop_replication_slot('slot1') FROM pg_replication_slots WHERE active = 'f';"}
```
**Azione suggerita**
Per risolvere la situazione, controlla la configurazione di replica per individuare eventuali problemi con i dati o lo schema di destinazione che potrebbero determinare la terminazione del processo di applicazione. I problemi più comuni sono i seguenti:
+ Colonne mancanti
+ Tipi di dati incompatibili
+ Mancata corrispondenza dei dati
+ Tabella mancante
Se il problema è legato a problemi relativi all’infrastruttura:
+ Problemi di rete: consulta [Come posso risolvere i problemi relativi a un database Amazon RDS in uno stato di rete incompatibile?](https://repost.aws/knowledge-center/rds-incompatible-network)
+ Il database o l’istanza database non è disponibile per i seguenti motivi:
+ L’istanza di replica ha esaurito lo spazio di archiviazione: per informazioni su come aggiungere spazio di archiviazione, consulta la pagina che spiega [cosa fare quando le istanze database Amazon RDS esauriscono lo spazio di archiviazione](https://repost.aws/knowledge-center/rds-out-of-storage).
+ Parametri incompatibili: per ulteriori informazioni su cosa fare, consulta [Come posso risolvere i problemi di un’istanza database Amazon RDS bloccata nello stato parametri incompatibili?](https://repost.aws/knowledge-center/rds-incompatible-parameters)
Se l’istanza si trova al di fuori della rete AWS oppure su AWS EC2, contatta l’utente amministratore per sapere come risolvere i problemi relativi alla disponibilità o all’infrastruttura.
**Eliminazione dello slot inattivo**
**avvertimento**
Attenzione: prima di eliminare uno slot di replica, verifica con attenzione che non vi sia alcun processo di replica in esecuzione, e che lo slot sia inattivo e sia in uno stato irreversibile. Se uno slot viene eliminato troppo presto, la replica potrebbe interrompersi oppure potrebbe verificarsi una perdita di dati.
Dopo aver verificato che lo slot di replica non è più necessario, eliminalo per far sì che il processo di autovacuum possa continuare. La condizione `active = 'f'` garantisce che uno slot venga eliminato solo se inattivo.
```
SELECT pg_drop_replication_slot('slot1') WHERE active ='f'
```
## Repliche di lettura
Quando l’impostazione `hot_standby_feedback` è abilitata per le [repliche di lettura di Amazon RDS](USER_PostgreSQL.Replication.ReadReplicas.md), il processo di autovacuum sul database primario non riesce a rimuovere le righe morte che potrebbero essere ancora necessarie per le query in esecuzione sulla replica di lettura. Questo influisce su tutti i tipi di replica di lettura fisica, inclusi quelli gestiti con o senza slot di replica. Questo comportamento è necessario perché le query in esecuzione sulla replica in standby richiedono che tali righe rimangano disponibili sul nodo primario, prevenendo [conflitti](https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT) e annullamenti delle query.
**Replica di lettura con slot di replica fisica**
Le repliche di lettura con slot di replica fisica migliorano in modo significativo l’affidabilità e la stabilità della replica in RDS per PostgreSQL. Questi slot assicurano che il database primario conservi i file WAL (Write-Ahead Log) essenziali finché il processo di replica non li elabora, mantenendo la coerenza dei dati anche durante le interruzioni della rete.
A partire dalla versione 14 di RDS per PostgreSQL, tutte le repliche utilizzano slot di replica. Nelle versioni precedenti, solo le repliche tra Regioni utilizzavano slot di replica.
La funzione `postgres_get_av_diag()` visualizza un output simile a quando segue quando individua in una replica di lettura con slot di replica fisica un elemento bloccante.
```
blocker | Read replica with physical replication slot
database |
blocker_identifier | rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxxx
wait_event | Not applicable
autovacuum_lagging_by | 554,080,689
suggestion | Run the following query on the replica "rds_us_west_2_db_xxxxxxxxxxxxxxxxxxxx" to find the long running query:
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. + |
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 757989377;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Replica di lettura con replica in streaming**
Amazon RDS consente di configurare repliche di lettura senza uno slot di replica fisica nelle versioni precedenti, fino alla versione 13. Questo approccio riduce il sovraccarico consentendo al nodo primario di riciclare i file WAL in modo più aggressivo, il che è vantaggioso in ambienti con spazio su disco limitato e può tollerare ReplicaLag occasionali. Tuttavia, senza uno slot, la replica in standby deve rimanere sincronizzata per evitare file WAL mancanti. Amazon RDS utilizza file WAL archiviati per consentire alla replica di recuperare gli eventuali ritardi, ma questo processo richiede un monitoraggio accurato e può essere lento.
La funzione `postgres_get_av_diag()` visualizza un output simile a quanto segue quando individua in una replica di lettura in streaming un elemento bloccante.
```
blocker | Read replica with streaming replication slot
database | Not applicable
blocker_identifier | xx.x.x.xxx/xx
wait_event | Not applicable
autovacuum_lagging_by | 610,146,760
suggestion | Run the following query on the replica "xx.x.x.xxx" to find the long running query: +
| SELECT * FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343; +
| Review carefully and you may consdier terminating the query on read replica using suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide. +
|
suggested_action | {"SELECT pg_terminate_backend(pid) FROM pg_catalog.pg_stat_activity WHERE backend_xmin::text::bigint = 348319343;"," +
| [OR] +
| ","Disable hot_standby_feedback"," +
| [OR] +
| ","Delete the read replica if not needed"}
```
**Azione suggerita**
Come consigliato nella colonna `suggested_action`, esamina attentamente queste opzioni per sbloccare il processo di autovacuum.
+ **Terminare la query**: seguendo le indicazioni riportate nella colonna dei suggerimenti, puoi connetterti alla replica di lettura, come specificato nella colonna suggested\$1action; è consigliabile esaminare attentamente l’opzione per terminare la sessione. Se è sicuro eseguire la terminazione, è possibile utilizzare la funzione `pg_terminate_backend()` per terminare la sessione. Questa azione può essere eseguita da un utente amministratore (come l’account principale RDS) o da un utente con il privilegio pg\$1terminate\$1backend() richiesto.
È possibile eseguire il seguente comando SQL sulla replica di lettura per terminare la query che impedisce al processo di autovacuum sul nodo primario di eseguire la pulizia delle righe meno recenti. Il valore di `backend_xmin` è riportato nell’output della funzione:
```
SELECT
pg_terminate_backend(pid)
FROM
pg_catalog.pg_stat_activity
WHERE
backend_xmin::text::bigint = backend_xmin;
```
+ **Disabilitare il feedback in modalità hot standby**: valuta la possibilità di disabilitare il parametro `hot_standby_feedback` se causa ritardi significativi nel processo di vacuum.
Il parametro `hot_standby_feedback` consente a una replica di lettura di informare il nodo primario sulla relativa attività di query, impedendo al nodo primario di eseguire il processo di vacuum sulle tabelle o sulle righe in uso sulla replica in standby. Se da un lato ciò garantisce la stabilità delle query sulla replica in standby, dall’altro può ritardare in modo significativo il processo di vacuum sul nodo primario. Disabilitando questa funzionalità il nodo primario può eseguire il processo di vacuum senza attendere la riattivazione dallo stato di standby. Tuttavia, ciò può comportare l’annullamento delle query o errori della replica in standby in caso di tentativo di accedere alle righe che sono state sottoposte a vacuum dal nodo primario.
+ **Eliminare la replica di lettura se non è più necessaria**: se la replica di lettura non è più necessaria, è possibile eliminarla. In questo modo, viene rimosso il sovraccarico di replica associato e il nodo primario può riciclare i log delle transazioni senza alcun ostacolo da parte della replica.
## Tabelle temporanee
Le [tabelle temporanee](https://www.postgresql.org/docs/current/sql-createtable.html), create utilizzando la parola chiave `TEMPORARY`, risiedono nello schema temporaneo (ad esempio, pg\$1temp\$1xxx) e sono accessibili solo alla sessione che le ha create. Le tabelle temporanee vengono eliminate al termine della sessione. Tuttavia, queste tabelle sono invisibili al processo di autovacuum di PostgreSQL e devono sottoposte manualmente a vacuum dalla sessione che le ha create. Il tentativo di eseguire il processo di vacuum sulla tabella temporanea da un’altra sessione non ha alcun effetto.
In circostanze insolite, una tabella temporanea esiste senza che una sessione attiva ne sia proprietaria. Se la sessione proprietaria si conclude inaspettatamente a causa di un crash irreversibile, di un problema di rete o di un evento simile, è possibile che la pulizia della tabella temporanea non venga eseguita e che di conseguenza la tabella rimanga “orfana”. Quando il processo di autovacuum di PostgreSQL rileva una tabella temporanea orfana, registra il seguente messaggio:
```
LOG: autovacuum: found orphan temp table \"%s\".\"%s\" in database \"%s\"
```
La funzione `postgres_get_av_diag()` visualizza un output simile a quanto segue quando identifica in una tabella temporanea un elemento bloccante. Affinché la funzione mostri correttamente l’output relativo alle tabelle temporanee, deve essere eseguita all’interno dello stesso database in cui esistono tali tabelle.
```
blocker | Temporary table
database | my_database
blocker_identifier | pg_temp_14.ttemp
wait_event | Not applicable
autovacuum_lagging_by | 1,805,802,632
suggestion | Connect to database "my_database". Review carefully, you may consider dropping temporary table using command in suggested_action. For more information, see Working with PostgreSQL autovacuum in the Amazon RDS User Guide.
suggested_action | {"DROP TABLE ttemp;"}
```
**Azione suggerita**
Segui le istruzioni fornite nella colonna `suggestion` dell’output per identificare e rimuovere la tabella temporanea che impedisce l’esecuzione del processo di autovacuum. Utilizza il comando seguente per eliminare la tabella temporanea riportata da `postgres_get_av_diag()`. Sostituisci il nome della tabella in base all’output fornito dalla funzione `postgres_get_av_diag()`.
```
DROP TABLE my_temp_schema.my_temp_table;
```
La seguente query può essere utilizzata per identificare le tabelle temporanee:
```
SELECT
oid,
relname,
relnamespace::regnamespace,
age(relfrozenxid)
FROM
pg_class
WHERE
relpersistence = 't'
ORDER BY
age(relfrozenxid) DESC;
```
# Risoluzione dei blocchi non identificabili per i processi di vacuum in RDS per PostgreSQL
Questa sezione esplora ulteriori motivi che possono impedire l’avanzamento del processo di autovacuum. Al momento tali problemi non sono direttamente identificabili tramite la funzione `postgres_get_av_diag()`.
**Topics**
+ [Pagine non valide](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages)
+ [Incoerenza dell’indice](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Index_inconsistency)
+ [Tasso di transazione eccezionalmente elevato](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.High_transaction_rate)
## Pagine non valide
Un errore di pagina non valida si verifica quando PostgreSQL rileva una mancata corrispondenza nel checksum di una pagina durante l’accesso a tale pagina. I contenuti sono illeggibili, il che impedisce al processo di autovacuum di bloccare le tuple. Ciò arresta in modo efficace il processo di pulizia. Il seguente errore è scritto nel log di PostgreSQL:
```
WARNING: page verification failed, calculated checksum YYYYY but expected XXXX
ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX
CONTEXT: automatic vacuum of table myschema.mytable
```
**Come determinare il tipo di oggetto**
```
ERROR: invalid page in block 4305910 of relation base/16403/186752608
WARNING: page verification failed, calculated checksum 50065 but expected 60033
```
Dal messaggio di errore, il percorso `base/16403/186752608` fornisce le seguenti informazioni:
+ “base” è il nome della directory all’interno della directory di dati PostgreSQL.
+ “16403” è l’OID del database, che puoi cercare nel catalogo di sistema `pg_database`.
+ “186752608” è il `relfilenode`, che puoi utilizzare per cercare lo schema e il nome dell’oggetto nel catalogo di sistema `pg_class`.
Controllando l’output della seguente query nel database interessato, è possibile determinare il tipo di oggetto. La seguente query recupera le informazioni sull’oggetto per oid: 186752608. Sostituisci l’OID con quello relativo all’errore riscontrato.
```
SELECT
relname AS object_name,
relkind AS object_type,
nspname AS schema_name
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.oid = 186752608;
```
Per ulteriori informazioni, consulta [https://www.postgresql.org/docs/current/catalog-pg-class.html](https://www.postgresql.org/docs/current/catalog-pg-class.html) nella documentazione di PostgreSQL per trovare tutti i tipi di oggetto supportati, indicati nella colonna `relkind` in `pg_class`.
**Linea guida**
La soluzione più efficace per questo problema dipende dalla configurazione dell’istanza Amazon RDS specifica e dal tipo di dati interessati dalla pagina incoerente.
**Se il tipo di oggetto è un indice:**
Si consiglia di ricreare l’indice.
+ **Utilizzo dell’opzione `CONCURRENTLY`**: prima della versione 12 di PostgreSQL, per ricreare un indice era richiesto un blocco di tabella esclusivo, che limitava l’accesso alla tabella. Con la versione 12 di PostgreSQL e le versioni successive, l’opzione `CONCURRENTLY` consente di eseguire il blocco a livello di riga e ciò migliora la disponibilità della tabella in modo significativo. Il comando è il seguente:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Sebbene `CONCURRENTLY` sia meno dannoso, può essere più lento sulle tabelle particolarmente utilizzate. Se possibile, valuta la possibilità di creare l’indice durante i periodi di traffico ridotto.
Per ulteriori informazioni, consulta [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) nella documentazione di PostgreSQL.
+ **Utilizzo dell’opzione `INDEX_CLEANUP FALSE`**: se gli indici sono di grandi dimensioni e si stima che richiedano un lungo lasso di tempo per completare l’operazione, puoi sbloccare l’autovacuum eseguendo un `VACUUM FREEZE` manuale escludendo gli indici. Questa funzionalità è disponibile in PostgreSQL 12 e versioni successive.
Bypassare gli indici ti consentirà di saltare il processo di vacuum dell’indice incoerente e mitigare il problema di wraparound. Tuttavia, ciò non risolverà il problema presente alla base e relativo alla pagina non valida. Per risolvere completamente il problema relativo alla pagina non valida, dovrai comunque ricreare l’indice.
**Se il tipo di oggetto è una vista materializzata:**
Se si verifica un errore di pagina non valida in una vista materializzata, accedi al database interessato e aggiornalo per risolvere la pagina non valida.
Aggiorna la vista materializzata.
```
REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;
```
Se l’aggiornamento non riesce, prova a eseguire una nuova creazione:
```
DROP MATERIALIZED VIEW schema_name.materialized_view_name;
CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;
```
L’aggiornamento o la nuova creazione della vista materializzata la ripristina senza influire sui dati della tabella sottostante.
**Per tutti gli altri tipi di oggetto:**
Per tutti gli altri tipi di oggetto, contatta l’assistenza AWS.
## Incoerenza dell’indice
Un indice logicamente incoerente può impedire il progresso del processo di autovacuum. I seguenti errori o errori simili vengono registrati durante la fase di vacuum dell’indice o quando si accede all’indice tramite istruzioni SQL.
```
ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
```
```
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX
CONTEXT: while vacuuming index index_name of relation schema.table
```
**Linea guida**
Ricrea l’indice o salta gli indici utilizzando `INDEX_CLEANUP` sul `VACUUM FREEZE` manuale. Per informazioni su come creare nuovamente l’indice, consulta [Se il tipo di oggetto è un indice](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Invalid_pages).
+ **Utilizzo dell’opzione CONCURRENTLY**: prima della versione 12 di PostgreSQL, per ricreare un indice era richiesto un blocco di tabella esclusivo, che limitava l’accesso alla tabella Con la versione 12 di PostgreSQL e le versioni successive, l’opzione CONCURRENTLY consente di eseguire il blocco a livello di riga e ciò migliora la disponibilità della tabella in modo significativo. Il comando è il seguente:
```
REINDEX INDEX ix_name CONCURRENTLY;
```
Sebbene CONCURRENTLY sia meno dannoso, può essere più lento sulle tabelle particolarmente utilizzate. Se possibile, valuta la possibilità di creare l’indice durante i periodi di traffico ridotto. Per ulteriori informazioni, consulta [REINDEX](https://www.postgresql.org/docs/current/sql-reindex.html) nella documentazione di *PostgreSQL*.
+ **Utilizzo dell’opzione INDEX\$1CLEANUP FALSE**: se gli indici sono di grandi dimensioni e si stima che richiedano un lungo lasso di tempo per completare l’operazione, puoi sbloccare l’autovacuum eseguendo un VACUUM FREEZE manuale escludendo gli indici. Questa funzionalità è disponibile in PostgreSQL 12 e versioni successive.
Bypassare gli indici ti consentirà di saltare il processo di vacuum dell’indice incoerente e mitigare il problema di wraparound. Tuttavia, ciò non risolverà il problema presente alla base e relativo alla pagina non valida. Per risolvere completamente il problema relativo alla pagina non valida, dovrai comunque ricreare l’indice.
## Tasso di transazione eccezionalmente elevato
In PostgreSQL, i tassi di transazione elevati possono influire in modo significativo sulle prestazioni di autovacuum, portando a una pulizia più lenta delle tuple inattive e a un aumento del rischio di wraparound dell’ID di transazione. È possibile monitorare il tasso di transazione misurando la differenza in `max(age(datfrozenxid))` tra due periodi di tempo, in genere al secondo. Inoltre, puoi utilizzare le seguenti metriche dei contatori di Approfondimenti sulle prestazioni di RDS per misurare il tasso di transazione (la somma di xact\$1commit e xact\$1rollback) che è il numero totale delle transazioni.
| Contatore | Tipo | Unità | Parametro |
| --- | --- | --- | --- |
| xact\$1commit | Transazioni | Commit al secondo | db.Transactions.xact\$1commit |
| xact\$1rollback | Transazioni | Rollback al secondo | db.Transactions.xact\$1rollback |
Un aumento rapido indica un carico di transazioni elevato, che può sovraccaricare il processo di autovacuum, con conseguenti aumento di dimensioni, conflitti di blocco e potenziali problemi di prestazioni. Ciò può influire negativamente sul processo di autovacuum in due modi:
+ **Attività delle tabelle:** la tabella specifica in fase di vacuum potrebbe registrare un volume elevato di transazioni, con conseguenti ritardi.
+ **Risorse di sistema:** l’intero sistema potrebbe essere sovraccarico e ciò rende difficile per l’autovacuum accedere alle risorse necessarie per garantire un funzionamento efficiente.
Esamina le seguenti strategie per consentire all’autovacuum di funzionare in modo più efficace e tenere il passo con le sue attività:
1. Riduzione, se possibile, del tasso di transazioni. Possibilità di raggruppare le transazioni simili, ove applicabile.
1. Concentrazione delle tabelle aggiornate di frequente con operazioni `VACUUM FREEZE` manuali con frequenza notturna, settimanale o bisettimanale nelle ore non di punta.
1. Possibilità di aumentare verticalmente la classe di istanza per allocare più risorse di sistema al fine di gestire l’elevato volume di transazioni e l’autovacuum.
# Risoluzione dei problemi relativi alle prestazioni di vacuum in RDS per PostgreSQL
Questa sezione illustra i fattori che spesso contribuiscono a rallentare le prestazioni di vacuum e spiega come risolvere tali problemi.
**Topics**
+ [Processo di vacuum su indici di grandi dimensioni](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Large_indexes)
+ [Quantità eccessiva di tabelle o database da sottoporre a vacuum](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Multiple_tables)
+ [Esecuzione di un processo di vacuum aggressivo (per evitare il wraparound)](#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum)
## Processo di vacuum su indici di grandi dimensioni
Il processo VACUUM funziona in fasi sequenziali: inizializzazione, scansione degli heap, vacuum di indici e heap, pulizia degli indici, troncamento degli heap e pulizia finale. Durante la scansione degli heap, il processo elimina alcune pagine, le deframmenta e le blocca. Dopo aver completato la scansione degli heap, VACUUM pulisce gli indici, restituisce le pagine vuote al sistema operativo ed esegue le attività di pulizia finale, come il vacuum della mappa dello spazio libero e l’aggiornamento delle statistiche.
Il processo di vacuum degli indici può richiedere più passaggi quando `maintenance_work_mem` (o `autovacuum_work_mem`) è insufficiente per elaborare l’indice. In PostgreSQL 16 e versioni precedenti, poiché per l’archiviazione degli ID delle tuple morte esisteva un limite di memoria di 1 GB, spesso era obbligatorio eseguire più passaggi sugli indici di grandi dimensioni. In PostgreSQL 17 è stato introdotto `TidStore`, che alloca la memoria in modo dinamico anziché utilizzare un array con allocazione singola. In questo modo viene eliminato il vincolo di 1 GB, la memoria viene utilizzata in modo più efficiente e viene ridotta la necessità di scansioni multiple per ogni indice.
È comunque possibile che gli indici di grandi dimensioni richiedano più passaggi in PostgreSQL 17 se la memoria disponibile non è in grado di supportare l’elaborazione simultanea degli interi indici. In genere, gli indici di dimensioni maggiori contengono un numero superiore di tuple morte che richiedono più passaggi.
**Rilevamento di operazioni di vacuum a esecuzione lenta**
La funzione `postgres_get_av_diag()` è in grado di rilevare le situazioni in cui le operazioni di vacuum vengono eseguite lentamente per memoria insufficiente. Per ulteriori informazioni su questa funzione, consulta [Installazione di strumenti di diagnostica e monitoraggio dei processi di autovacuum in RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Installation.md).
La funzione `postgres_get_av_diag()` genera i seguenti avvisi quando la memoria disponibile non è sufficiente per completare il processo di vacuum di un indice in un singolo passaggio.
**`rds_tools` 1.8**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is "XXX" and might not be sufficient. Consider increasing the setting, and if necessary, scaling up the Amazon RDS instance class for more memory.
Additionally, review the possibility of manual vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;).
```
**`rds_tools` 1.9**
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_work_mem is XX might not be sufficient. Consider increasing the setting to XXX, and if necessary, scaling up the RDS instance class for more
memory. The suggested value is an estimate based on the current number of dead tuples for the table being vacuumed, which might not fully reflect the latest state. Additionally, review the possibility of manual
vacuum with exclusion of indexes using (VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) table_name;). For more information, see
[Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html)
.
```
**Nota**
La funzione `postgres_get_av_diag()` si affida a `pg_stat_all_tables.n_dead_tup` per stimare la quantità di memoria richiesta per il vacuum dell’indice.
Quando identifica un’operazione di vacuum a esecuzione lenta che richiede più scansioni dell’indice per `autovacuum_work_mem` insufficiente, la funzione `postgres_get_av_diag()` genera il seguente messaggio:
```
NOTICE: Your vacuum is performing multiple index scans due to insufficient autovacuum_work_mem:XXX for index vacuuming.
For more information, see [Working with PostgreSQL autovacuum in the Amazon Amazon RDS User Guide](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html).
```
**Linea guida**
È possibile avvalersi delle seguenti soluzioni alternative utilizzando il processo `VACUUM FREEZE` manuale per velocizzare il blocco della tabella.
**Incremento della memoria per il processo di vacuum**
Come suggerito dalla funzione `postgres_get_av_diag()`, è consigliabile incrementare il valore del parametro `autovacuum_work_mem` per superare potenziali vincoli di memoria a livello di istanza. Sebbene `autovacuum_work_mem` sia un parametro dinamico, per applicare la nuova impostazione di memoria occorre che il daemon di autovacuum riavvii i propri worker. A tale scopo, procedi come segue:
1. Verifica che la nuova impostazione sia effettiva.
1. Termina i processi che hanno in corso un’operazione di autovacuum.
Questo approccio garantisce che la nuova quantità di memoria allocata venga applicata alle successive operazioni di autovacuum.
Per risultati più immediati, valuta la possibilità di eseguire manualmente un’operazione `VACUUM FREEZE` con un’impostazione `maintenance_work_mem` incrementata nella sessione in corso:
```
SET maintenance_work_mem TO '1GB';
VACUUM FREEZE VERBOSE table_name;
```
Se utilizzi Amazon RDS e ritieni di aver bisogno di memoria aggiuntiva per supportare valori più elevati per `maintenance_work_mem` o `autovacuum_work_mem`, valuta la possibilità di passare a una classe di istanze con più memoria. Tale operazione può fornire le risorse necessarie per ottimizzare sia le operazioni di vacuum manuali che quelle automatiche, con conseguente miglioramento delle prestazioni complessive del database e del processo di vacuum.
**Disabilitazione di INDEX\$1CLEANUP**
Il processo `VACUUM` manuale in PostgreSQL versione 12 e successive consente di saltare la fase di pulizia degli indici, mentre l’autovacuum di emergenza in PostgreSQL versione 14 e successive esegue tale operazione automaticamente in base al parametro [https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-VACUUM-FAILSAFE-AGE).
**avvertimento**
La mancata esecuzione della pulizia degli indici può causare il bloat degli indici e influire negativamente sulle prestazioni delle query. Per risolvere questo problema, valuta la possibilità di eseguire una nuova indicizzazione o un’operazione di vacuum sugli indici interessati durante una finestra di manutenzione.
Per ulteriori indicazioni sulla gestione degli indici di grandi dimensioni, consulta la pagina [Gestione di autovacuum con indici di grandi dimensioni](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.md).
**Vacuum degli indici in parallelo**
A partire da PostgreSQL 13, gli indici possono essere sottoposti a vacuum e pulizia in parallelo per impostazione predefinita tramite un’operazione `VACUUM` manuale, con un processo worker di vacuum assegnato a ciascun indice. Tuttavia, affinché PostgreSQL possa determinare se un’operazione di vacuum è idonea per l’esecuzione in parallelo, occorre che siano soddisfatti criteri specifici:
+ Devono esistere almeno due indici.
+ Il parametro `max_parallel_maintenance_workers` deve essere impostato almeno su 2.
+ Le dimensioni degli indici devono superare il limite di `min_parallel_index_scan_size`, che è di 512 KB per impostazione predefinita.
L’impostazione `max_parallel_maintenance_workers` può essere modificata in base al numero di vCPU disponibili nell’istanza Amazon RDS in uso e al numero di indici nella tabella per ottimizzare i tempi di risposta del processo di vacuum.
Per ulteriori informazioni, consulta [Parallel vacuuming in Amazon RDS per PostgreSQL and Amazon Aurora PostgreSQL](https://aws.amazon.com/blogs/database/parallel-vacuuming-in-amazon-rds-for-postgresql-and-amazon-aurora-postgresql/).
## Quantità eccessiva di tabelle o database da sottoporre a vacuum
Come descritto nella sezione [The Autovacuum Daemon](https://www.postgresql.org/docs/current/routine-vacuuming.html#AUTOVACUUM') della documentazione di PostgreSQL, il daemon di autovacuum opera attraverso l’esecuzione di più processi. È incluso un programma di avvio automatico persistente responsabile dell’avvio dei processi worker di autovacuum per ogni database all’interno del sistema. Il programma di avvio pianifica l’avvio dei worker affinché si verifichi all’incirca ogni `autovacuum_naptime` secondi per database.
Con N database, un nuovo processo worker viene avviato approssimativamente ogni [`autovacuum_naptime`/N secondi]. Tuttavia, il numero totale di processi worker simultanei è limitato dall’impostazione `autovacuum_max_workers`. Se il numero di database o di tabelle che richiedono un processo di vacuum supera tale limite, l’elaborazione del database successivo o della tabella successiva avverrà non appena sarà disponibile un processo worker.
Quando è necessario eseguire il processo di vacuum su più tabelle o database di grandi dimensioni contemporaneamente, tutti i processi worker di autovacuum disponibili possono rimanere occupati per un periodo di tempo prolungato, ritardando così la manutenzione di altri database e tabelle. In ambienti con grandi volumi di transazioni, questo collo di bottiglia può peggiorare rapidamente e potenzialmente causare problemi con il processo di vacuum per wraparound nell’istanza Amazon RDS in uso.
Quando `postgres_get_av_diag()` rileva un numero elevato di tabelle o database, fornisce il seguente suggerimento:
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound and it might be slow.
```
```
NOTICE: The current setting of autovacuum_max_workers:3 might not be sufficient. Consider increasing the setting and, if necessary, consider scaling up the Amazon RDS instance class for more workers.
```
**Linea guida**
**Incremento del numero di autovacuum\$1max\$1workers**
Per velocizzare il processo di vacuum, si consiglia di regolare il parametro `autovacuum_max_workers` per consentire l’utilizzo simultaneo di più processi worker di autovacuum. Se continuano a verificarsi colli di bottiglia nelle prestazioni, valuta la possibilità di aumentare verticalmente le risorse dell’istanza Amazon RDS in uso passando a una classe con più vCPU, così da migliorare ulteriormente le capacità di elaborazione in parallelo.
## Esecuzione di un processo di vacuum aggressivo (per evitare il wraparound)
L’età del database (MaximumUsedTransactionIDs) in PostgreSQL diminuisce solo dopo il corretto completamento di un processo di vacuum aggressivo (per evitare il wraparound). Fino al completamento di tale processo di vacuum, l’età continua ad aumentare in funzione del volume di transazioni.
La funzione `postgres_get_av_diag()` genera il seguente messaggio `NOTICE` quando rileva un processo di vacuum aggressivo. ma attiva questo output solo dopo che il processo di vacuum è rimasto attivo per almeno due minuti.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Per ulteriori informazioni sui processi di vacuum aggressivi, consulta la sezione [Scenario in cui è già in esecuzione un processo di vacuum aggressivo](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.NOTICE.md).
È possibile verificare se è in corso un processo di vacuum aggressivo utilizzando la seguente query:
```
SELECT
a.xact_start AS start_time,
v.datname "database",
a.query,
a.wait_event,
v.pid,
v.phase,
v.relid::regclass,
pg_size_pretty(pg_relation_size(v.relid)) AS heap_size,
(
SELECT
string_agg(pg_size_pretty(pg_relation_size(i.indexrelid)) || ':' || i.indexrelid::regclass || chr(10), ', ')
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS index_sizes,
trunc(v.heap_blks_scanned * 100 / NULLIF(v.heap_blks_total, 0)) AS step1_scan_pct,
v.index_vacuum_count || '/' || (
SELECT
count(*)
FROM
pg_index i
WHERE
i.indrelid = v.relid
) AS step2_vacuum_indexes,
trunc(v.heap_blks_vacuumed * 100 / NULLIF(v.heap_blks_total, 0)) AS step3_vacuum_pct,
age(CURRENT_TIMESTAMP, a.xact_start) AS total_time_spent_sofar
FROM
pg_stat_activity a
INNER JOIN pg_stat_progress_vacuum v ON v.pid = a.pid;
```
È possibile determinare se si tratta di un processo di vacuum aggressivo (per evitare il wraparound) controllando la colonna della query nell’output. La dicitura “to prevent wraparound” (letteralmente, per evitare il wraparound) indica che si tratta di un processo di vacuum aggressivo.
```
query | autovacuum: VACUUM public.t3 (to prevent wraparound)
```
Ad esempio, si supponga di avere un elemento bloccante corrispondente a un’età delle transazioni pari a 1 miliardo e una tabella che richiede un processo di vacuum aggressivo per evitare il wraparound in corrispondenza dello stesso valore di età delle transazioni. Inoltre, esiste un altro elemento bloccante corrispondente a un’età delle transazioni pari a 750 milioni. Una volta eliminato l’elemento bloccante corrispondente a un’età delle transazioni pari a 1 miliardo, l’età delle transazioni non scende immediatamente a 750 milioni, ma rimane elevata fino al completamento della tabella che richiede un processo di vacuum aggressivo o di eventuali transazioni con età superiore a 750 milioni. Durante tale periodo, l’età delle transazioni del cluster PostgreSQL continua a crescere. Una volta completato il processo di vacuum, l’età delle transazioni scende a 750 milioni e quindi ricomincia ad aumentare fino al termine di un ulteriore processo di vacuum. Questo ciclo continua fintanto che persistono le suddette condizioni, ossia finché l’età delle transazioni non sarà scesa al livello configurato per l’istanza Amazon RDS in uso, specificato dal parametro `autovacuum_freeze_max_age`.
# Spiegazione dei messaggi NOTICE in RDS per PostgreSQL
La funzione `postgres_get_av_diag()` fornisce i seguenti messaggi NOTICE:
**Scenario in cui l’età non ha ancora raggiunto la soglia di monitoraggio**
Per impostazione predefinita, la soglia di monitoraggio per `postgres_get_av_diag()` che consente di identificare gli elementi bloccanti è di 500 milioni di transazioni. Se `postgres_get_av_diag()` genera il seguente messaggio NOTICE, significa che l’età delle transazioni non ha ancora raggiunto tale soglia.
```
NOTICE: postgres_get_av_diag() checks for blockers that prevent aggressive vacuums only, it does so only after exceeding dvb_threshold which is 500,000,000 and age of this PostgreSQL cluster is currently at 2.
```
**Mancata connessione al database con l’età dell’ID transazione meno recente**
La funzione `postgres_get_av_diag()` fornisce l’output più accurato quando è connessa al database con l’età dell’ID transazione meno recente. Nel caso in questione, il database con l’età dell’ID transazione meno recente riportato da `postgres_get_av_diag()` è diverso da “my\$1database”. In caso di mancata connessione al database corretto, viene generato il seguente messaggio NOTICE:
```
NOTICE: You are not connected to the database with the age of oldest transaction ID. Connect to my_database database and run postgres_get_av_diag() for accurate reporting.
```
La connessione al database con l’età della transazione meno recente è importante per i seguenti motivi:
+ **Identificazione degli elementi bloccanti costituiti da tabelle temporanee:** i metadati per le tabelle temporanee sono specifici di ogni database, pertanto solitamente sono contenuti nel database in cui sono stati creati. Tuttavia, se una tabella temporanea è l’elemento bloccante principale ed è contenuta nel database con la transazione meno recente, la situazione potrebbe risultare fuorviante. La connessione al database corretto garantisce l’identificazione accurata dell’elemento bloccante costituito da una tabella temporanea.
+ **Diagnosi dei problemi correlati a processi di vacuum a esecuzione lenta:** le informazioni sul numero di tabelle e i metadati degli indici sono specifici di ogni database e sono necessari per diagnosticare eventuali problemi correlati a processi di vacuum a esecuzione lenta.
**Scenario in cui il database con la transazione meno recente per età è un database rdsadmin o template0**
In alcuni casi, è possibile che un database `rdsadmin` o `template0` venga identificato come il database con l’età dell’ID transazione meno recente. In tali casi, `postgres_get_av_diag()` genera il seguente messaggio NOTICE:
```
NOTICE: The database with the age of oldest transaction ID is rdsadmin or template0, reach out to support if the reported blocker is in rdsadmin or template0.
```
Verifica che l’elemento bloccante indicato non provenga da nessuno di questi due database. Se viene segnalata la presenza dell’elemento bloccante nel database `rdsadmin` o `template0`, contatta il supporto poiché tali database non sono accessibili all’utente e richiedono un intervento.
È altamente improbabile che il database `rdsadmin` o `template0` contenga un elemento bloccante principale.
**Scenario in cui è già in esecuzione un processo di vacuum aggressivo**
La funzione `postgres_get_av_diag()` è progettata per segnalare quando è in corso un processo di vacuum aggressivo, ma attiva questo output solo dopo che il processo di vacuum è rimasto attivo per almeno 1 minuto. Questo ritardo intenzionale aiuta a ridurre le possibilità di falsi positivi. L’attesa fa sì che la funzione segnali solo i processi di vacuum efficaci e significativi, permettendo un monitoraggio più accurato e affidabile dell’attività di vacuum.
La funzione `postgres_get_av_diag()` genera il seguente messaggio NOTICE quando rileva uno o più processi di vacuum aggressivi in esecuzione.
```
NOTICE: Your database is currently running aggressive vacuum to prevent wraparound, monitor autovacuum performance.
```
Come indicato nel messaggio NOTICE, occorre continuare a monitorare le prestazioni dell’attività di vacuum. Per ulteriori informazioni sui processi di vacuum aggressivi, consulta [Esecuzione di un processo di vacuum aggressivo (per evitare il wraparound)](Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Resolving_Performance.md#Appendix.PostgreSQL.CommonDBATasks.Autovacuum_Monitoring.Aggressive_vacuum).
**Scenario in cui la funzionalità di autovacuum è disattivata**
La funzione `postgres_get_av_diag()` genera il seguente messaggio NOTICE se la funzionalità di autovacuum è disabilitata in un’istanza database:
```
NOTICE: Autovacuum is OFF, we strongly recommend to enable it, no restart is necessary.
```
Autovacuum è una funzionalità fondamentale delle istanze database RDS per PostgreSQL in quanto garantisce il corretto funzionamento del database. Essa rimuove automaticamente le versioni precedenti delle righe, recupera spazio di archiviazione e impedisce il bloat delle tabelle, garantendo così l’efficacia di tabelle e indici per prestazioni ottimali. Inoltre, evita il wraparound degli ID transazione, che può interrompere le transazioni sulle istanze Amazon RDS. Disabilitando la funzionalità di autovacuum, è possibile che la stabilità e le prestazioni del database subiscano una riduzione a lungo termine. Pertanto suggeriamo di lasciarla sempre attivata. Per ulteriori informazioni, consulta [Informazioni sull’autovacuum in ambienti RDS per PostgreSQL](https://aws.amazon.com/blogs/database/understanding-autovacuum-in-amazon-rds-for-postgresql-environments/).
La disattivazione della funzionalità di autovacuum non blocca i processi di vacuum aggressivi. Tali problemi continueranno a verificarsi quando le tabelle raggiungeranno la soglia `autovacuum_freeze_max_age`.
**Scenario in cui il numero di transazioni rimanenti è estremamente basso**
La funzione `postgres_get_av_diag()` genera il seguente messaggio NOTICE quando è imminente un processo di vacuum per wraparound. Questo messaggio NOTICE viene generato quando, in un’istanza Amazon RDS, mancano solo 100 milioni di transazioni prima che possa verificarsi il rifiuto di nuove transazioni.
```
WARNING: Number of transactions remaining is critically low, resolve issues with autovacuum or perform manual VACUUM FREEZE before your instance stops accepting transactions.
```
È necessaria un’azione immediata per evitare un tempo di inattività del database. Occorre monitorare attentamente le operazioni di vacuum e valutare la possibilità di avviare manualmente un processo `VACUUM FREEZE` sul database interessato per evitare errori nelle transazioni.
# Gestione di un numero elevato di oggetti in Amazon RDS for PostgreSQL Amazon Aurora
Sebbene le limitazioni di PostgreSQL siano teoriche, avere un numero di oggetti estremamente elevato in un database causerà un notevole impatto sulle prestazioni di varie operazioni. Questa documentazione copre diversi tipi di oggetti comuni che, quando hanno un numero totale elevato, possono portare a diversi possibili impatti.
La tabella seguente fornisce un riepilogo dei tipi di oggetti e dei loro potenziali impatti:
**Tipi di oggetti e potenziali impatti**
| Tipo di oggetto | Autovacuum | Replica logica | Aggiornamento della versione principale | pg\$1dump/pg\$1restore | Prestazioni generali | Riavvio dell'istanza |
| --- | --- | --- | --- | --- | --- | --- |
| [Relazioni](#PostgreSQL.HighObjectCount.Relations) | x | | x | x | x | |
| [Tabelle temporanee](#PostgreSQL.HighObjectCount.TempTables) | x | | | | x | |
| [Tabelle non registrate](#PostgreSQL.HighObjectCount.UnloggedTables) | | x | | | | x |
| [Partizioni](#PostgreSQL.HighObjectCount.Partitions) | | | | | x | |
| [File temporanei](#PostgreSQL.HighObjectCount.TempFiles) | | | | | x | |
| [Sequenze](#PostgreSQL.HighObjectCount.Sequences) | | x | | | | |
| [Oggetti di grandi dimensioni](#PostgreSQL.HighObjectCount.LargeObjects) | | x | x | | | |
## Relazioni
Non esiste un limite rigido specifico per quanto riguarda il numero di tabelle in un database PostgreSQL. Il limite teorico è estremamente elevato, ma ci sono altri limiti pratici che devono essere tenuti a mente durante la progettazione del database.
**Impatto: l'aspirapolvere automatico rimane indietro**
Autovacuum può avere difficoltà a tenere il passo con la crescita degli ID delle transazioni o l'aumento dei tavoli a causa della mancanza di lavoratori rispetto alla quantità di lavoro.
**Azione consigliata:** Esistono diversi fattori per ottimizzare l'autovacuum in modo che stia al passo con un determinato numero di tabelle e un determinato carico di lavoro. Vedi [Best practice per lavorare con PostgreSQL autovacuum Best practice per lavorare con PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) .
**Impatto: aggiornamento della versione principale /pg\$1dump e ripristino**
Amazon RDS utilizza l'opzione «--link» durante l'esecuzione di pg\$1upgrade per evitare di dover fare copie dei file di dati, i metadati dello schema devono comunque essere ripristinati nella nuova versione del database. Anche con parallel pg\$1restore, se esiste un numero significativo di relazioni, ciò aumenterà la quantità di tempi di inattività.
**Impatto: degrado generale delle prestazioni**
Degrado generale delle prestazioni dovuto alle dimensioni del catalogo. Ogni tabella e le colonne associate verranno aggiunte alle `pg_attribute` `pg_depend` tabelle utilizzate di frequente nelle normali operazioni del database. `pg_class` Non sarà visibile un evento di attesa specifico, ma l'efficienza del buffer condiviso ne risentirà.
**Azione consigliata:** controlla regolarmente il gonfiamento della tabella per queste tabelle specifiche e occasionalmente esegui un errore `VACUUM FULL` su queste tabelle specifiche. Tieni presente che `VACUUM FULL` sulle tabelle del catalogo è necessario un `ACCESS EXCLUSIVE` blocco, il che significa che nessun'altra interrogazione potrà accedervi fino al completamento dell'operazione.
**Impatto: esaurimento del descrittore di file**
Errore: «descrittori di file insufficienti: troppi file aperti nel sistema; rilascia e riprova». Il `max_files_per_process` parametro PostgreSQL determina il numero di file che ogni processo può aprire. Se è presente un numero elevato di connessioni che uniscono un numero elevato di tabelle, è possibile raggiungere questo limite.
**Azione consigliata:**
+ La riduzione del valore del parametro `max_files_per_process` può contribuire a ridurre questo errore. Ogni processo e sottoprocesso (ad esempio, query parallela) può aprire questo numero di file e, se le query uniscono più tabelle, questo limite può essere esaurito.
+ Riduci il numero complessivo di connessioni e utilizza un pool di connessioni come [Amazon RDS Proxy Amazon](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) o altre soluzioni come. PgBouncer [Per ulteriori informazioni, consulta il sito Web. PgBouncer ](https://www.pgbouncer.org/)
**Impatto: esaurimento degli inodi**
Errore: «Spazio insufficiente sul dispositivo». Se ciò si verifica quando c'è molto spazio libero di archiviazione, ciò è causato dall'esaurimento degli inode. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) offre visibilità sugli inode in uso e sul numero massimo disponibile per l'host.
**Soglia approssimativa**[: milioni](#PostgreSQL.HighObjectCount.Note)
## Tabelle temporanee
L'utilizzo di tabelle temporanee è utile per i dati di test o i risultati intermedi ed è uno schema comune utilizzato in molti motori di database. Le implicazioni dell'uso intensivo di PostgreSQL devono essere comprese per evitare alcune delle insidie. Ogni creazione e rilascio di tabelle temporanee aggiungerà righe alle tabelle del catalogo di sistema, che, una volta gonfiate, causeranno problemi generali di prestazioni.
**Impatto: Autovacuum è in ritardo**
Le tabelle temporanee non vengono cancellate dall'autovacuum, ma rimarranno invariate per tutta la durata della loro esistenza e, se non vengono IDs rimosse, possono causare problemi.
**Azione consigliata:** le tabelle temporanee resteranno attive per tutta la durata della sessione che le ha create o possono essere eliminate manualmente. Una buona pratica per evitare transazioni di lunga durata con tabelle temporanee impedirà a queste tabelle di contribuire alla crescita massima degli ID di transazione utilizzati.
**Impatto: degrado generale delle prestazioni**
Degrado generale delle prestazioni dovuto alle dimensioni del catalogo. Quando le sessioni creano ed eliminano continuamente tabelle temporanee, si aggiungono `pg_class` alle `pg_attribute` `pg_depend` tabelle utilizzate di frequente nelle normali operazioni del database. Non sarà visibile un evento di attesa specifico, ma l'efficienza del buffer condiviso ne risentirà.
**Azione consigliata:**
+ Controlla regolarmente table bloat per queste tabelle specifiche e occasionalmente esegui un a `VACUUM FULL` su queste tabelle specifiche. Tieni presente che `VACUUM FULL` sulle tabelle del catalogo è necessario un `ACCESS EXCLUSIVE` blocco, il che significa che nessun'altra interrogazione potrà accedervi fino al completamento dell'operazione.
+ Se le tabelle temporanee vengono utilizzate intensamente, prima di un aggiornamento della versione principale, si consiglia vivamente di utilizzare una `VACUUM FULL` di queste tabelle di catalogo specifiche per ridurre i tempi di inattività.
**Procedure consigliate generali:**
+ Riduci l'uso di tabelle temporanee utilizzando espressioni di tabella comuni per produrre risultati intermedi. A volte possono complicare le interrogazioni necessarie, ma eliminano gli impatti sopra elencati.
+ Riutilizza le tabelle temporanee utilizzando il `TRUNCATE` comando per cancellare il contenuto anziché eseguire i passaggi. drop/create Ciò eliminerà anche il problema della crescita degli ID delle transazioni causata dalle tabelle temporanee.
**Soglia approssimativa:** [decine di migliaia](#PostgreSQL.HighObjectCount.Note)
## Tabelle non registrate
Le tabelle non registrate possono offrire miglioramenti in termini di prestazioni in quanto non generano alcuna informazione WAL. Devono essere utilizzate con attenzione in quanto non offrono alcuna durabilità durante il ripristino da un crash del database poiché verranno troncate. Questa è un'operazione costosa in PostgreSQL poiché ogni tabella non registrata viene troncata in serie. Sebbene questa operazione sia rapida per un numero limitato di tabelle non registrate, quando si contano migliaia può iniziare ad aggiungere notevoli ritardi durante l'avvio.
**Impatto: replica logica**
Le tabelle non registrate generalmente non sono incluse nella replica logica, incluse le [implementazioni blue/verdi](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html), poiché la replica logica si .
**Impatto: tempi di inattività prolungati durante il ripristino**
Durante qualsiasi stato del database che comporti il ripristino da un arresto anomalo del database, ad esempio il riavvio Multi-AZ con failover, il ripristino di Amazon RDS point-in-time e l'aggiornamento della versione principale di Amazon RDS, si verificherà l'operazione serializzata di troncamento delle tabelle non registrate. Ciò può portare a tempi di inattività molto più lunghi del previsto.
**Azione consigliata:**
+ Riduci al minimo l'uso di tabelle non registrate solo per i dati la cui perdita è accettabile durante le operazioni di ripristino da crash del database.
+ Riduci al minimo l'uso di tabelle non registrate poiché l'attuale comportamento del troncamento seriale può causare una notevole quantità di tempo per l'avvio di un database.
**Buone pratiche generali:**
+ Le tabelle non registrate non sono a prova di crash. L'avvio di un point-in-time ripristino, che prevede il ripristino in caso di arresto anomalo, richiede molto tempo in PostgreSQL perché si tratta di un processo seriale che tronca ogni tabella.
**[Soglia](#PostgreSQL.HighObjectCount.Note)** approssimativa: migliaia
## Partizioni
Il partizionamento può aumentare le prestazioni delle query e fornire un'organizzazione logica dei dati. In scenari ideali, il partizionamento è organizzato in modo da poter utilizzare l'eliminazione delle partizioni durante la pianificazione e l'esecuzione delle query. L'utilizzo di troppe partizioni può avere un impatto negativo sulle prestazioni delle query e sulla manutenzione del database. La scelta del modo in cui partizionare una tabella deve essere effettuata con attenzione, poiché le prestazioni della pianificazione e dell'esecuzione delle query possono essere influenzate negativamente da una progettazione scadente. Consulta la [documentazione di PostgreSQL per i dettagli sul partizionamento](https://www.postgresql.org/docs/current/ddl-partitioning.html).
**Impatto: peggioramento generale delle prestazioni**
A volte il sovraccarico di tempo di pianificazione aumenta e la spiegazione dei piani per le domande diventa più complicata, rendendo difficile l'identificazione delle opportunità di ottimizzazione. Per le versioni di PostgreSQL precedenti alla 18, molte partizioni con un carico di lavoro elevato possono causare attese. `LWLock:LockManager`
**Azione consigliata:** Determina un numero minimo di partizioni che ti consenta di completare l'organizzazione dei dati e allo stesso tempo di fornire un'esecuzione delle query efficiente.
**Impatto: complessità della manutenzione**
Un numero molto elevato di partizioni introdurrà difficoltà di manutenzione come la precreazione e la rimozione. Autovacuum tratterà le partizioni come normali relazioni e dovrà eseguire una pulizia regolare, richiedendo quindi un numero sufficiente di lavoratori per completare l'operazione.
**Azione consigliata:**
+ Assicurati di precreare le partizioni in modo che il carico di lavoro non venga bloccato quando è necessaria una nuova partizione (ad esempio, partizioni mensili) e le vecchie partizioni vengono eliminate.
+ Assicurati di disporre di un numero sufficiente di aspiratori automatici per eseguire la normale pulizia e manutenzione di tutte le partizioni.
**[Soglia](#PostgreSQL.HighObjectCount.Note)** approssimativa: centinaia
## File temporanei
A differenza delle tabelle temporanee sopra menzionate, i file temporanei vengono creati da PostgreSQL quando una query complessa può eseguire diverse operazioni di ordinamento o hash contemporaneamente, con ogni operazione che utilizza la memoria dell'istanza per archiviare i risultati fino al valore specificato nel parametro. `work_mem` Quando la memoria dell'istanza non è sufficiente, vengono creati file temporanei per archiviare i risultati. Vedi [Gestione dei file temporanei Gestione dei file](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.ManagingTempFiles.html) . Se il carico di lavoro genera un numero elevato di questi file, gli impatti possono essere diversi.
**Impatto: esaurimento del descrittore di file**
Errore: «descrittori di file insufficienti: troppi file aperti nel sistema; rilascia e riprova». Il `max_files_per_process` parametro PostgreSQL determina il numero di file che ogni processo può aprire. Se è presente un numero elevato di connessioni che uniscono un numero elevato di tabelle, è possibile raggiungere questo limite.
**Azione consigliata:**
+ La riduzione del valore del parametro `max_files_per_process` può contribuire a ridurre questo errore. Ogni processo e sottoprocesso (ad esempio, query parallela) può aprire questo numero di file e, se le query uniscono più tabelle, questo limite può essere esaurito.
+ Riduci il numero complessivo di connessioni e utilizza un pool di connessioni come [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) o altre soluzioni come. PgBouncer [Per ulteriori informazioni, consulta il PgBouncer sito Web.](https://www.pgbouncer.org/)
**Impatto: esaurimento degli inodi**
Errore: «Spazio insufficiente sul dispositivo». Se ciò si verifica quando c'è molto spazio libero di archiviazione, ciò è causato dall'esaurimento degli inode. [Amazon RDS Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) offre la visibilità degli inode in uso e il numero massimo disponibile per l'host.
**Best practice generali:**
+ Monitora l'utilizzo dei file temporanei con [Performance Insights Performance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) .
+ Ottimizza le query che generano file temporanei significativi per vedere se è possibile ridurre il numero totale di file temporanei.
**Soglia approssimativa**[: migliaia](#PostgreSQL.HighObjectCount.Note)
## Sequenze
Le sequenze sono l'oggetto sottostante utilizzato per l'incremento automatico delle colonne in PostgreSQL e forniscono unicità e una chiave per i dati. Queste possono essere utilizzate su singole tabelle senza conseguenze durante le normali operazioni, ad eccezione della replica logica.
In PostgreSQL, la replica logica attualmente non replica il valore corrente di una sequenza su nessun sottoscrittore. Per saperne di più, consulta la [pagina Restrizioni nella documentazione di PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html).
**Impatto: tempo di commutazione prolungato**
Se prevedi di utilizzare [Amazon RDS Blue/Green Deployments](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) per qualsiasi tipo di modifica o aggiornamento della configurazione, è importante comprendere l'impatto di un numero elevato di sequenze sullo switchover. Una delle ultime fasi di uno switchover sincronizzerà il valore corrente delle sequenze e, se ce ne sono diverse migliaia, ciò aumenterà il tempo complessivo di passaggio.
**Azione consigliata:** se il carico di lavoro del database consentisse l'uso di un UUID condiviso anziché di un sequence-per-table approccio, ciò ridurrebbe la fase di sincronizzazione durante lo switchover.
**[Soglia approssimativa: migliaia](#PostgreSQL.HighObjectCount.Note)**
## Oggetti di grandi dimensioni
Gli oggetti di grandi dimensioni vengono memorizzati in un'unica tabella di sistema denominata pg\$1largeobject. Ogni oggetto di grandi dimensioni ha anche una voce nella tabella di sistema pg\$1largeobject\$1metadata. Questi oggetti vengono creati, modificati e ripuliti in modo molto diverso rispetto alle relazioni standard. Gli oggetti di grandi dimensioni non vengono gestiti dall'autovacuum e devono essere puliti periodicamente tramite un processo separato chiamato vacuumlo. Vedi Gestione di oggetti di grandi dimensioni con il modulo lo per esempi sulla gestione di oggetti di grandi dimensioni.
**Impatto: replica logica**
Gli oggetti di grandi dimensioni non vengono attualmente replicati in PostgreSQL durante la replica logica. Per saperne di più, consulta la [pagina Restrizioni nella documentazione di PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). In una configurazione [blu/verde blu/verde](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) .
**Impatto: aggiornamento della versione principale**
Un aggiornamento può esaurire la memoria e fallire se sono presenti milioni di oggetti di grandi dimensioni e l'istanza non è in grado di gestirli durante l'aggiornamento. Il processo di aggiornamento della versione principale di PostgreSQL comprende due ampie fasi: il dumping dello schema tramite pg\$1dump e il ripristino tramite pg\$1restore. Se il tuo database ha milioni di oggetti di grandi dimensioni, devi assicurarti che l'istanza abbia memoria sufficiente per gestire pg\$1dump e pg\$1restore durante un aggiornamento e ridimensionarla su un tipo di istanza più grande.
**Migliori pratiche generali:**
+ Utilizzate regolarmente l'utilità vacuumlo per rimuovere eventuali oggetti di grandi dimensioni rimasti orfani.
+ Prendi in considerazione l'utilizzo del tipo di dati BYTEA per archiviare i tuoi oggetti di grandi dimensioni nel database.
**[Soglia approssimativa: milioni](#PostgreSQL.HighObjectCount.Note)**
## Soglie approssimative
Le soglie approssimative menzionate in questo argomento vengono utilizzate solo per fornire una stima della scalabilità di una determinata risorsa. Rappresentano l'intervallo generale in cui gli impatti descritti diventano più probabili, ma il comportamento effettivo dipende dal carico di lavoro specifico, dalla dimensione dell'istanza e dalla configurazione. Sebbene sia possibile superare queste stime, è necessario attenersi alla cura e alla manutenzione in modo da evitare gli impatti elencati.
#
TOAST (The Oversized-Attribute Storage Technique) è una funzionalità di PostgreSQL progettata per gestire grandi valori di dati che superano la dimensione tipica dei blocchi di database di 8 KB. PostgreSQL non consente alle righe fisiche di estendersi su più blocchi. La dimensione del blocco funge da limite superiore alla dimensione delle righe. TOAST supera questa restrizione suddividendo i valori di campo di grandi dimensioni in blocchi più piccoli. Li memorizza separatamente in una tabella TOAST dedicata collegata alla tabella principale. Per ulteriori informazioni, consulta il meccanismo di archiviazione [TOAST di PostgreSQL e la documentazione di implementazione](https://www.postgresql.org/docs/current/storage-toast.html).
**Topics**
+ [Comprendere le operazioni TOAST](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.HowWorks)
+ [Identificazione delle sfide prestazionali](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.PerformanceChallenges)
+ [Raccomandazioni](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Recommendations)
+ [Monitoraggio](#Appendix.PostgreSQL.CommonDBATasks.TOAST_OID.Monitoring)
## Comprendere le operazioni TOAST
TOAST esegue la compressione e memorizza valori di campo di grandi dimensioni fuori linea. TOAST assegna un OID (Object Identifier) univoco a ogni blocco di dati di grandi dimensioni archiviato nella tabella TOAST. La tabella principale memorizza l'ID del valore TOAST e l'ID della relazione sulla pagina per fare riferimento alla riga corrispondente nella tabella TOAST. Ciò consente a PostgreSQL di localizzare e gestire in modo efficiente questi blocchi TOAST. Tuttavia, man mano che la tabella TOAST cresce, il sistema rischia di esaurire le risorse disponibili OIDs, con conseguente peggioramento delle prestazioni e potenziali tempi di inattività dovuti all'esaurimento degli OID.
### Identificatori di oggetti in TOAST
Un Object Identifier (OID) è un identificatore univoco a livello di sistema utilizzato da PostgreSQL per fare riferimento a oggetti del database come tabelle, indici e funzioni. Questi identificatori svolgono un ruolo fondamentale nelle operazioni interne di PostgreSQL, consentendo al database di localizzare e gestire gli oggetti in modo efficiente.
Per le tabelle con set di dati idonei per il toast, PostgreSQL assegna l'identificazione univoca di ogni blocco di dati di OIDs grandi dimensioni archiviato nella tabella TOAST associata. Il sistema associa ogni blocco a un`chunk_id`, che aiuta PostgreSQL a organizzare e localizzare questi blocchi in modo efficiente all'interno della tabella TOAST.
## Identificazione delle sfide prestazionali
La gestione degli OID di PostgreSQL si basa su un contatore globale a 32 bit, che viene eseguito dopo aver generato 4 miliardi di valori univoci. Sebbene il cluster di database condivida questo contatore, l'allocazione OID prevede due passaggi durante le operazioni TOAST:
+ **Contatore globale per l'allocazione**: il contatore globale assegna un nuovo OID al cluster.
+ **Ricerca locale dei conflitti**: la tabella TOAST garantisce che il nuovo OID non entri in conflitto con quelli esistenti OIDs già utilizzati in quella tabella specifica.
Il peggioramento delle prestazioni può verificarsi quando:
+ La tabella TOAST presenta un'elevata frammentazione o un uso intensivo dell'OID, con conseguenti ritardi nell'assegnazione dell'OID.
+ Il sistema esegue spesso allocazioni e riutilizzi OIDs in ambienti con un elevato tasso di abbandono dei dati o tabelle ampie che utilizzano ampiamente TOAST.
Per ulteriori informazioni, consulta i limiti di dimensione della [tabella TOAST di PostgreSQL e la documentazione](https://wiki.postgresql.org/wiki/TOAST#Total_table_size_limit) sull'allocazione OID:
Un contatore globale genera OIDs e riassume ogni 4 miliardi di valori, in modo che di tanto in tanto il sistema generi nuovamente un valore già utilizzato. PostgreSQL lo rileva e riprova con l'OID successivo. Un INSERT lento potrebbe verificarsi se c'è una serie molto lunga di valori OID usati senza spazi vuoti nella tabella TOAST. Queste problematiche diventano più evidenti man mano che lo spazio OID si riempie, con conseguente rallentamento degli inserimenti e degli aggiornamenti.
### Identificazione del problema
+ `INSERT`Le affermazioni semplici richiedono molto più tempo del solito in modo incoerente e casuale.
+ I ritardi si verificano solo per le `UPDATE` dichiarazioni che `INSERT` coinvolgono operazioni TOAST.
+ Le seguenti voci di registro vengono visualizzate nei log di PostgreSQL quando il sistema fatica a trovare la disponibilità nelle tabelle TOAST: OIDs
```
LOG: still searching for an unused OID in relation "pg_toast_20815"
DETAIL: OID candidates have been checked 1000000 times, but no unused OID has been found yet.
```
+ Performance Insights indica un numero elevato di sessioni attive medie (AAS) associate `LWLock:buffer_io` a eventi di `LWLock:OidGenLock` attesa.
È possibile eseguire la seguente query SQL per identificare transazioni INSERT di lunga durata con eventi di attesa:
```
SELECT
datname AS database_name,
usename AS database_user,
pid,
now() - pg_stat_activity.xact_start AS transaction_duration,
concat(wait_event_type, ':', wait_event) AS wait_event,
substr(query, 1, 30) AS TRANSACTION,
state
FROM
pg_stat_activity
WHERE (now() - pg_stat_activity.xact_start) > INTERVAL '60 seconds'
AND state IN ('active', 'idle in transaction', 'idle in transaction (aborted)', 'fastpath function call', 'disabled')
AND pid <> pg_backend_pid()
AND lower(query) LIKE '%insert%'
ORDER BY
transaction_duration DESC;
```
Esempi di risultati di query che mostrano le operazioni INSERT con tempi di attesa prolungati:
```
database_name | database_user | pid | transaction_duration | wait_event | transaction | state
---------------+-----------------+-------+----------------------+---------------------+--------------------------------+--------
postgres | db_admin_user| 70965 | 00:10:19.484061 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 69878 | 00:06:14.976037 | LWLock:buffer_io | INSERT INTO "products" (......... | active
postgres | db_admin_user| 68937 | 00:05:13.942847 | : | INSERT INTO "products" (......... | active
```
### Isolamento del problema
+ **Test small insert**: inserisce un record inferiore alla `toast_tuple_target` soglia. Ricorda che la compressione viene applicata prima dell'archiviazione TOAST. Se funziona senza problemi di prestazioni, il problema è legato alle operazioni TOAST.
+ **Prova una nuova tabella**: crea una nuova tabella con la stessa struttura e inserisci un record più grande di`toast_tuple_target`. Se funziona senza problemi, il problema viene localizzato nell'allocazione OID della tabella originale.
## Raccomandazioni
I seguenti approcci possono aiutare a risolvere i problemi di contesa di TOAST OID.
+ **Pulizia e archiviazione dei dati**: rivedi ed elimina tutti i dati obsoleti o non necessari per liberarli per utilizzi OIDs futuri o archivia i dati. Considera i seguenti limiti:
+ Scalabilità limitata, poiché le pulizie future potrebbero non essere sempre possibili.
+ Possibile operazione VACUUM a lunga durata per rimuovere le tuple morte risultanti.
+ **Scrivi su una nuova tabella**: crea una nuova tabella per inserti futuri e usa una `UNION ALL` vista per combinare dati vecchi e nuovi per le query. Questa visualizzazione presenta i dati combinati delle tabelle vecchie e nuove, consentendo alle query di accedervi come un'unica tabella. Considera i seguenti limiti:
+ Gli aggiornamenti sulla vecchia tabella potrebbero comunque causare l'esaurimento degli OID.
+ **Partizione o frammento**: partiziona i dati della tabella o del frammento per migliorare la scalabilità e le prestazioni. Considera i seguenti limiti:
+ Maggiore complessità nella logica e nella manutenzione delle query, potenziale necessità di modifiche alle applicazioni per gestire correttamente i dati partizionati.
## Monitoraggio
### Utilizzo delle tabelle di sistema
È possibile utilizzare le tabelle di sistema di PostgreSQL per monitorare la crescita dell'utilizzo degli OID.
**avvertimento**
A seconda del numero di elementi OIDs presenti nella tabella TOAST, il completamento potrebbe richiedere del tempo. Si consiglia di pianificare il monitoraggio durante le ore non lavorative per ridurre al minimo l'impatto.
Il seguente blocco anonimo conta il numero di elementi distinti OIDs utilizzati in ogni tabella TOAST e visualizza le informazioni della tabella principale:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
-- If there are used OIDs, find the associated parent table and its schema
IF o <> 0 THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Esempio di output che mostra le statistiche sull'utilizzo di OID tramite la tabella TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO
```
Il seguente blocco anonimo recupera l'OID massimo assegnato per ogni tabella TOAST non vuota:
```
DO $$
DECLARE
r record;
o bigint;
parent_table text;
parent_schema text;
BEGIN
SET LOCAL client_min_messages TO notice;
FOR r IN
SELECT
c.oid,
c.oid::regclass AS toast_table
FROM
pg_class c
WHERE
c.relkind = 't'
AND c.relowner != 10 LOOP
-- Fetch the max(chunk_id) from the TOAST table
EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
-- If there's at least one TOASTed chunk, find the associated parent table and its schema
IF o IS NOT NULL THEN
SELECT
n.nspname,
c.relname INTO parent_schema,
parent_table
FROM
pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE
c.reltoastrelid = r.oid;
-- Raise a concise NOTICE message
RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
END IF;
END LOOP;
END
$$;
```
Esempio di output che mostra il blocco massimo per le tabelle IDs TOAST:
```
NOTICE: Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE: Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE: Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO
```
### Uso di Approfondimenti sulle prestazioni
Gli eventi `LWLock:buffer_io` di attesa `LWLock:OidGenLock` vengono visualizzati in Performance Insights durante le operazioni che richiedono l'assegnazione di nuovi identificatori di oggetti ()OIDs. Le sessioni AAS (High Average Active Sessions) per questi eventi in genere indicano situazioni di conflitto durante l'assegnazione degli OID e la gestione delle risorse. Ciò è particolarmente comune in ambienti con un elevato tasso di abbandono dei dati, un utilizzo esteso di grandi quantità di dati o la creazione frequente di oggetti.
#### LWLockCiò è particolarmente comune in ambienti con un elevato tasso di abbandono dei dati, un ampio utilizzo di dati o la creazione frequente di oggetti. ----sep----:buffer\$1io
`LWLock:buffer_io`è un evento di attesa che si verifica quando una sessione PostgreSQL è in I/O attesa del completamento delle operazioni su un buffer condiviso. Ciò si verifica in genere quando il database legge i dati dal disco alla memoria o scrive pagine modificate dalla memoria al disco. L'evento di `BufferIO` attesa garantisce la coerenza impedendo a più processi di accedere o modificare lo stesso buffer mentre I/O le operazioni sono in corso. Un numero elevato di occorrenze di questo evento di attesa può indicare colli di bottiglia sul disco o un'attività eccessiva I/O nel carico di lavoro del database.
Durante le operazioni TOAST:
+ PostgreSQL OIDs alloca oggetti di grandi dimensioni e ne garantisce l'unicità scansionando l'indice della tabella TOAST.
+ Gli indici TOAST di grandi dimensioni possono richiedere l'accesso a più pagine per verificare l'unicità dell'OID. Ciò si traduce in un aumento dell'I/O del disco, specialmente quando il buffer pool non è in grado di memorizzare nella cache tutte le pagine richieste.
La dimensione dell'indice influisce direttamente sul numero di pagine buffer a cui è necessario accedere durante queste operazioni. Anche se l'indice non è gonfio, le sue dimensioni possono aumentare l'I/O del buffer, in particolare in ambienti con elevata concorrenza o elevato tasso di abbandono. [Per ulteriori informazioni, consulta:Guida alla risoluzione dei problemi relativi agli eventi Bufferio wait. LWLock](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lwlockbufferio.html)
#### LWLock:OidGenLock
`OidGenLock`è un evento di attesa che si verifica quando una sessione PostgreSQL è in attesa di allocare un nuovo identificatore di oggetto (OID). Questo blocco garantisce che OIDs vengano generati in modo sequenziale e sicuro, consentendo la generazione di un solo processo alla volta. OIDs
Durante le operazioni TOAST:
+ **Allocazione OID per blocchi nella tabella TOAST:** PostgreSQL assegna i blocchi nelle tabelle OIDs TOAST quando si gestiscono record di dati di grandi dimensioni. Ogni OID deve essere unico per evitare conflitti nel catalogo di sistema.
+ **Concorrenza elevata**: poiché l'accesso al generatore OID è sequenziale, quando più sessioni creano contemporaneamente oggetti che lo richiedono OIDs, possono verificarsi contese per. `OidGenLock` Ciò aumenta la probabilità che le sessioni attendano il completamento dell'allocazione OID.
+ **Dipendenza dall'accesso al catalogo di sistema: l'**allocazione OIDs richiede aggiornamenti alle tabelle del catalogo di sistema condiviso come e. `pg_class` `pg_type` Se queste tabelle presentano un'attività intensa (a causa di frequenti operazioni DDL), è possibile che si verifichi un aumento del conflitto di blocchi per. `OidGenLock`
+ **Elevata richiesta di allocazione OID**: i carichi di lavoro pesanti di TOAST con record di dati di grandi dimensioni richiedono un'allocazione OID costante, con conseguente aumento del conflitto.
Fattori aggiuntivi che aumentano la contesa OID:
+ **Creazione frequente di oggetti**: i carichi di lavoro che creano e rilasciano frequentemente oggetti, come le tabelle temporanee, amplificano il conflitto sul contatore OID globale.
+ **Controblocco globale: il contatore** OID globale è accessibile in serie per garantire l'unicità, creando un unico punto di contesa in ambienti ad alta concorrenza.
## Utilizzo dei meccanismi di registrazione supportati da RDS for PostgreSQL
Esistono diversi parametri, estensioni e altri elementi configurabili che è possibile impostare per registrare le attività che avvengono sull'istanza database PostgreSQL. Questi sono i seguenti:
+ Il parametro `log_statement` può essere utilizzato per registrare l'attività dell'utente nel database di PostgreSQL. Per ulteriori informazioni sulla registrazione di RDS per PostgreSQL e su come monitorare i registri, consulta [](USER_LogAccess.Concepts.PostgreSQL.md).
+ Il parametro `rds.force_admin_logging_level` registra le azioni dall'utente interno Amazon RDS (rdsadmin) nei database sull'istanza database. Scrive l'output nel registro degli errori PostgreSQL. I valori consentiti sono `disabled`, `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, log, `fatal` e `panic`. Il valore predefinito è `disabled`.
+ Il parametro `rds.force_autovacuum_logging_level` può essere impostato per acquisire varie operazioni di pulizia automatica nel registro degli errori PostgreSQL. Per ulteriori informazioni, consulta [Registrazione delle attività di autovacuum e vacuum](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.Logging.md).
+ L'estensione PostgreSQL Audit (pgAudit) può essere installata e configurata per acquisire attività a livello di sessione o a livello di oggetto. Per ulteriori informazioni, consulta [Utilizzo di pgAudit per registrare l'attività del database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md).
+ L’estensione `log_fdw` consente di accedere al registro del motore del database utilizzando SQL. Per ulteriori informazioni, consulta [Utilizzo dell'estensione log\$1fdw per accedere al registro di database utilizzando SQL](CHAP_PostgreSQL.Extensions.log_fdw.md).
+ La libreria `pg_stat_statements` è specificata come predefinita per il parametro `shared_preload_libraries` in RDS per PostgreSQL versione 10 e successive. È questa libreria che puoi utilizzare per analizzare le query in esecuzione. Assicurati che `pg_stat_statements` sia impostato nel gruppo parametri del database. Per ulteriori informazioni sul monitoraggio dell'istanza database RDS for PostgreSQL utilizzando le informazioni fornite da questa libreria, consulta [Statistiche SQL per RDS PostgreSQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.PostgreSQL.md).
+ Il parametro `log_hostname` acquisisce nel log il nome host di ogni connessione client. Per RDS per PostgreSQL versione 12 e successive, questo parametro è impostato su `off` per impostazione predefinita. Se lo attivi, assicurati di monitorare i tempi di connessione della sessione. Quando è attivo, il servizio utilizza la richiesta di ricerca inversa del sistema dei nomi di dominio (DNS) per ottenere il nome host del client che sta effettuando la connessione e aggiungerlo al log di PostgreSQL. Ciò ha un impatto notevole sulla connessione della sessione. Ti consigliamo di attivare questo parametro solo a scopo di risoluzione dei problemi.
In termini generali, lo scopo della registrazione è consentire a DBA di monitorare, ottimizzare le prestazioni e risolvere i problemi. Molti dei log vengono caricati automaticamente su Amazon CloudWatch o Performance Insights. Qui vengono ordinati e raggruppati per fornire parametri completi per l’istanza database. Per ulteriori informazioni sul monitoraggio e sui parametri di Amazon RDS, consulta [Monitoraggio di parametri in un'istanza Amazon RDS](CHAP_Monitoring.md).
# Gestione dei file temporanei con PostgreSQL
In PostgreSQL, una query complessa può eseguire più operazioni di ordinamento o hash contemporaneamente, ciascuna delle quali utilizza la memoria dell’istanza per archiviare i risultati fino al valore specificato nel parametro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Quando la memoria dell'istanza non è sufficiente, vengono creati file temporanei per archiviare i risultati. Questi vengono scritti su disco per completare l'esecuzione della query. Successivamente, questi file vengono rimossi automaticamente al completamento della query. In RDS per PostgreSQL, questi file vengono archiviati in Amazon EBS sul volume di dati. Per ulteriori informazioni, consulta [Storage delle istanze di database Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Puoi monitorare la `FreeStorageSpace` metrica pubblicata in CloudWatch per assicurarti che l'istanza DB disponga di spazio di archiviazione libero sufficiente. Per ulteriori informazioni, consulta [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm).
Consigliamo di utilizzare istanze di lettura ottimizzata per Amazon RDS per i carichi di lavoro che comportano più query simultanee che aumentano l’utilizzo di file temporanei. Questi di istanze utilizzano lo storage locale a livello di blocco basato su unità SSD (Solid State DriveNVMe) basate su Non-Volatile Memory Express () per collocare i file temporanei. Per ulteriori informazioni, consulta [Prestazioni delle query migliorate per RDS per PostgreSQL con Letture ottimizzate per Amazon RDS](USER_PostgreSQL.optimizedreads.md).
È possibile utilizzare i seguenti parametri e funzioni per gestire i file temporanei nell'istanza.
+ **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)**: questo parametro annulla qualsiasi query che superi la dimensione definita in KB dal parametro temp\$1files. Questo limite impedisce a qualsiasi query di essere eseguita all'infinito e di consumare spazio su disco con file temporanei. È possibile stimare il valore utilizzando i risultati del parametro `log_temp_files`. È consigliabile esaminare il comportamento del carico di lavoro e impostare il limite in base alla stima. Gli esempi seguenti mostrano come viene annullata una query quando supera il limite.
```
postgres=>select * from pgbench_accounts, pg_class, big_table;
```
```
ERROR: temporary file size exceeds temp_file_limit (64kB)
```
+ **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)**: questo parametro invia messaggi a postgresql.log quando i file temporanei di una sessione vengono rimossi. Questo parametro produce log dopo che una query è stata completata correttamente. Pertanto, potrebbe non essere utile nella risoluzione dei problemi delle query attive e con tempi di esecuzione lunghi.
L'esempio seguente mostra che quando la query viene completata correttamente, le voci vengono registrate nel file postgresql.log mentre i file temporanei vengono eliminati.
```
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800
2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10;
```
+ **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)**: questa funzione disponibile in RDS per PostgreSQL 13 e versioni successive fornisce visibilità sull'attuale utilizzo dei file temporanei. La query completata non viene visualizzata nei risultati della funzione. Nell'esempio seguente, è possibile visualizzare i risultati di questa funzione.
```
postgres=>select * from pg_ls_tmpdir();
```
```
name | size | modification
-----------------+------------+------------------------
pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00
pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00
pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00
pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00
pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00
pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00
(7 rows)
```
```
postgres=>select query from pg_stat_activity where pid = 8355;
query
----------------------------------------------------------------------------------------
select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid
(1 row)
```
Il nome del file include l'ID di elaborazione (PID) della sessione che ha generato il file temporaneo. Una query più avanzata, come nell'esempio seguente, esegue la somma dei file temporanei per ogni PID.
```
postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid;
```
```
pid | count | sum
------+-------------------
8355 | 2 | 2144501760
8351 | 2 | 2090770432
8327 | 1 | 1072250880
8328 | 2 | 2144501760
(4 rows)
```
+ **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`**: se attivi il parametro pg\$1stat\$1statements, puoi visualizzare l'utilizzo medio dei file temporanei per chiamata. È possibile identificare il valore query\$1id della query e utilizzarlo per esaminare l'utilizzo dei file temporanei, come illustrato nell'esempio seguente.
```
postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%';
```
```
queryid
----------------------
-7170349228837045701
(1 row)
```
```
postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701;
```
```
queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call
----------------------+---------------------------+-------+-------------------------+----------------------------
-7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678
(1 row)
```
+ **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: nel pannello di controllo di Approfondimenti sulle prestazioni, puoi visualizzare l'utilizzo dei file temporanei attivando le metriche **temp\$1bytes** e **temp\$1files**. Puoi quindi vedere la media di entrambe queste metriche e verificare se corrispondono al carico di lavoro delle query. La visualizzazione all'interno di Approfondimenti sulle prestazioni non evidenzia in modo specifico le query che generano file temporanei. Tuttavia, combinando le informazioni di Approfondimenti sulle prestazioni con la query mostrata per il parametro `pg_ls_tmpdir`, è possibile definire, analizzare e risolvere eventuali problemi a livello di modifiche del carico di lavoro delle query.
Per ulteriori informazioni su come analizzare metriche e query con Approfondimenti sulle prestazioni, consulta [Analisi delle metriche utilizzando il pannello di controllo Performance Insights](USER_PerfInsights.UsingDashboard.md).
Per un esempio di visualizzazione dell’utilizzo dei file temporanei con Approfondimenti sulle prestazioni, consulta [Visualizzazione dell’utilizzo dei file temporanei con Approfondimenti sulle prestazioni](PostgreSQL.ManagingTempFiles.Example.md).
# Visualizzazione dell’utilizzo dei file temporanei con Approfondimenti sulle prestazioni
È possibile utilizzare Approfondimenti sulle prestazioni per visualizzare l’utilizzo dei file temporanei attivando le metriche **temp\$1bytes** e **temp\$1files**. La visualizzazione in Approfondimenti sulle prestazioni non mostra le query specifiche che generano i file temporanei. Tuttavia, combinando Approfondimenti sulle prestazioni con la query mostrata per `pg_ls_tmpdir`, è possibile risolvere i problemi, analizzare e determinare le modifiche nel carico di lavoro delle query.
1. Nel pannello di controllo di Approfondimenti sulle prestazioni, scegli **Gestisci parametri**.
1. Seleziona **Metriche del database** e quindi seleziona le metriche **temp\$1bytes** e **temp\$1files** come illustrato nell'immagine seguente.
![\[I parametri sono visualizzati nel grafico.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png)
1. Nella scheda **SQL principale**, scegli l'icona **Preferenze**.
1. Nella finestra **Preferenze**, attiva le seguenti statistiche per visualizzarle nella scheda **SQL principale** e scegli **Continua**.
+ Scritture temporanee al secondo
+ Letture temporanee al secondo
+ Scritture temporanee in blocco a chiamata
+ Letture temporanee in blocco a chiamata
1. Il file temporaneo viene suddiviso quando viene combinato con la query visualizzata per `pg_ls_tmpdir`, come illustrato nell'esempio seguente.
![\[Query che visualizza l'utilizzo dei file temporanei.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png)
Gli eventi `IO:BufFileRead` e `IO:BufFileWrite` si verificano quando le query principali del carico di lavoro creano spesso file temporanei. Puoi utilizzare Approfondimenti sulle prestazioni per identificare le query di livello superiore in attesa di `IO:BufFileRead` e `IO:BufFileWrite` esaminando la metrica Sessioni attive medie (AAS) nelle sezioni Caricamento del database e SQL principale.
![\[IO: BufFileRead e IO: BufFileWrite nel grafico.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png)
Per ulteriori informazioni su come analizzare metriche principali ed eventi di attesa con Approfondimenti sulle prestazioni, consulta [Panoramica della scheda Prime istruzioni SQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Devi individuare e ottimizzare le query che causano un aumento dell'utilizzo dei file temporanei e dei relativi eventi di attesa. Per ulteriori informazioni su questi eventi di attesa e sulla correzione, vedere [IO: BufFileRead e IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) .
**Nota**
Il parametro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controlla quando l'operazione di ordinamento esaurisce la memoria; i risultati vengono scritti in file temporanei. Si consiglia di non modificare l'impostazione di questo parametro specificando un valore superiore al valore predefinito perché ciò causerebbe un maggiore utilizzo della memoria da parte di ciascuna sessione del database. Inoltre, una sessione che esegue unioni e ordinamenti complessi può eseguire operazioni parallele in cui ogni operazione consuma memoria.
Come best practice, in presenza di un report di grandi dimensioni con più unioni e ordinamenti, imposta questo parametro a livello di sessione utilizzando il comando `SET work_mem`. La modifica verrà quindi applicata solo alla sessione corrente e non comporterà la modifica del valore a livello globale.
## Utilizzo di pgBadger per l'analisi del registro con PostgreSQL
È possibile utilizzare un analizzatore di registro come [pgBadger](http://dalibo.github.io/pgbadger/) per analizzare i registri di PostgreSQL. La documentazione pgBadger afferma che il modello %l (la linea di registro per sessione o processo) dovrebbe essere una parte del prefisso. Tuttavia, se si fornisce l'attuale `log_line_prefix` RDS come parametro per pgBadger, dovrebbe comunque produrre un report.
Ad esempio, il comando seguente formatta correttamente un file di log Amazon RDS for PostgreSQL datato 04-02-2014 usando pgBadger.
```
./pgbadger -f stderr -p '%t:%r:%u@%d:[%p]:' postgresql.log.2014-02-04-00
```
## Utilizzo PGSnapper per il monitoraggio di PostgreSQL
Puoi utilizzarlo PGSnapper per fornire assistenza nella raccolta periodica di statistiche e metriche relative alle prestazioni di Amazon RDS for PostgreSQL. Per ulteriori informazioni, consulta [Monitorare le prestazioni di Amazon RDS for PostgreSQL utilizzando. PGSnapper](https://aws.amazon.com/blogs/database/monitor-amazon-rds-for-postgresql-and-amazon-aurora-postgresql-performance-using-pgsnapper/)
#
Il **type casting** in PostgreSQL è il processo di conversione di un valore da un tipo di dati a un altro. PostgreSQL fornisce cast integrati per molte conversioni comuni, ma puoi anche creare cast personalizzati per definire come devono comportarsi le conversioni di tipi specifici.
Un cast specifica come eseguire una conversione da un tipo di dati a un altro. Ad esempio, la conversione di testo `'123'` in numero intero `123` o di numeri `45.67` in testo. `'45.67'`
[Per informazioni complete sui concetti e sulla sintassi del casting di PostgreSQL, consulta la documentazione PostgreSQL CREATE CAST.](https://www.postgresql.org/docs/current/sql-createcast.html)
A partire dalle per installare cast aggiuntivi per tipi integrati, pur potendo creare cast personalizzati tipi.
**Topics**
+ [Installazione e utilizzo dell'estensione rds\$1casts](#PostgreSQL.CustomCasts.Installing)
+ [Cast supportati](#PostgreSQL.CustomCasts.Supported)
+ [Creare o eliminare cast](#PostgreSQL.CustomCasts.Creating)
+ [Creazione di cast personalizzati con una strategia contestuale adeguata](#PostgreSQL.CustomCasts.BestPractices)
## Installazione e utilizzo dell'estensione rds\$1casts
Per creare l'`rds_casts`estensione, connettiti all' ed esegui il comando seguente: `rds_superuser`
```
CREATE EXTENSION IF NOT EXISTS rds_casts;
```
## Cast supportati
Crea l'estensione in ogni database in cui desideri utilizzare i cast personalizzati. Dopo aver creato l'estensione, utilizzate il seguente comando per visualizzare tutti i cast disponibili:
```
SELECT * FROM rds_casts.list_supported_casts();
```
Questa funzione elenca le combinazioni di cast disponibili (tipo di origine, tipo di destinazione, contesto di coercizione e funzione di cast). Ad esempio, se vuoi `text` crearlo `numeric` come cast. `implicit` Puoi usare la seguente query per scoprire se il cast è disponibile per la creazione:
```
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
```
L'estensione rds\$1casts fornisce due tipi di funzioni di conversione per ogni cast:
+ *funzioni \$1inout*: utilizzano il meccanismo di I/O conversione standard di PostgreSQL, che si comporta in modo identico ai cast creati con il metodo INOUT
+ *\$1custom functions*: forniscono una logica di conversione avanzata che gestisce i casi limite, come la conversione di stringhe vuote in valori NULL per evitare errori di conversione
Le `inout` funzioni replicano il comportamento di casting nativo di PostgreSQL, mentre `custom` le funzioni estendono questa funzionalità gestendo scenari che i cast INOUT standard non sono in grado di supportare, come la conversione di stringhe vuote in numeri interi.
## Creare o eliminare cast
Puoi creare e eliminare i cast supportati utilizzando due metodi:
### Creazione di cast
**Metodo 1: utilizzo del comando CREATE CAST nativo**
```
CREATE CAST (text AS numeric)
WITH FUNCTION rds_casts.rds_text_to_numeric_custom
AS IMPLICIT;
```
**Metodo 2: utilizzo della funzione rds\$1casts.create\$1cast**
```
SELECT rds_casts.create_cast(10);
```
La funzione prende l'ID dall'output. `create_cast` `list_supported_casts()` Questo metodo è più semplice e garantisce l'utilizzo della combinazione corretta di funzione e contesto. È garantito che questo id rimanga lo stesso tra le diverse versioni di postgres.
Per verificare che il cast sia stato creato correttamente, interroga il catalogo del sistema pg\$1cast:
```
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
```
La `castcontext` colonna mostra: `e` per EXPLICIT, per ASSIGNMENT o `a` per IMPLICIT. `i`
### Eliminare i calchi
**Metodo 1: utilizzo del comando DROP CAST**
```
DROP CAST IF EXISTS (text AS numeric);
```
**Metodo 2: utilizzo della funzione rds\$1casts.drop\$1cast**
```
SELECT rds_casts.drop_cast(10);
```
La `drop_cast` funzione accetta lo stesso ID utilizzato durante la creazione del cast. Questo metodo assicura che tu stia eliminando il cast esatto creato con l'ID corrispondente.
## Creazione di cast personalizzati con una strategia contestuale adeguata
Quando si creano più cast per tipi interi, possono verificarsi errori di ambiguità dell'operatore se tutti i cast vengono creati come IMPLICITI. L'esempio seguente dimostra questo problema creando due cast impliciti dal testo a diverse larghezze di numeri interi:
```
-- 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.
```
L'errore si verifica perché PostgreSQL non è in grado di determinare quale cast implicito utilizzare quando si confronta una colonna intera con un valore di testo. Entrambi i cast impliciti int4 e int8 sono candidati validi, il che crea ambiguità.
Per evitare questa ambiguità dell'operatore, usa il contesto ASSIGNMENT per larghezze intere più piccole e il contesto IMPLICIT per larghezze intere più grandi:
```
-- 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)
```
Con questa strategia, solo il cast int8 è implicito, quindi PostgreSQL può determinare in modo inequivocabile quale cast utilizzare.
# Best practice per le query parallele in PostgreSQL RDS per PostgreSQL
L'esecuzione parallela delle query è una funzionalità di PostgreSQL che consente di suddividere una singola query SQL in attività più piccole che vengono elaborate contemporaneamente da più processi di lavoro in background. Invece di eseguire una query interamente in un unico processo di backend, PostgreSQL può distribuire parti della query, come scansioni, join, aggregazioni o ordinamento, su più core della CPU. Il *processo leader* coordina questa esecuzione e raccoglie i risultati dai *parallel worker*.
Tuttavia, per la maggior parte dei carichi di lavoro di produzione, in particolare i sistemi OLTP ad alta concorrenza, consigliamo di disabilitare l'esecuzione automatica delle query parallele. Sebbene il parallelismo possa accelerare le interrogazioni su set di dati di grandi dimensioni nei carichi di lavoro di analisi o reporting, introduce rischi significativi che spesso superano i vantaggi in ambienti di produzione affollati.
L'esecuzione parallela comporta inoltre un notevole sovraccarico. Ogni parallel worker è un processo backend PostgreSQL completo, che richiede il forking del processo (copia delle strutture di memoria e inizializzazione dello stato del processo) e l'autenticazione (utilizzo degli slot di connessione oltre il limite). `max_connections` Inoltre, ogni worker utilizza la propria memoria, anche `work_mem` per le operazioni di ordinamento e hashing, con più worker per query, l'utilizzo della memoria si moltiplica rapidamente (ad esempio, 4 worker × 64 MB = 256 MB per query). `work_mem` Di conseguenza, le query parallele possono consumare molte più risorse di sistema rispetto alle query a processo singolo. Se non ottimizzati correttamente, possono portare alla saturazione della CPU (più worker sovraccaricano la capacità di elaborazione disponibile), a un aumento del cambio di contesto (il sistema operativo passa spesso da un processo di lavoro all'altro, aggiungendo un sovraccarico e riducendo il throughput) o all'esaurimento della connessione (poiché ogni worker parallelo consuma uno slot di connessione, una singola query con 4 worker utilizza 5 connessioni in totale, 1 leader e 4 worker, che possono esaurire rapidamente il pool di connessioni in caso di elevata concorrenza, impedendo nuove connessioni connessioni client e cause di errori delle applicazioni). Questi problemi sono particolarmente gravi nei carichi di lavoro ad alta concorrenza in cui più query possono tentare l'esecuzione parallela contemporaneamente.
PostgreSQL decide se utilizzare il parallelismo in base alle stime dei costi. In alcuni casi, il pianificatore può passare automaticamente a un piano parallelo se sembra più economico anche se in pratica non è ideale. Ciò può accadere se le statistiche dell'indice sono obsolete o se il bloat rende le scansioni sequenziali più interessanti delle ricerche nell'indice. A causa di questo comportamento, i piani paralleli automatici possono talvolta introdurre regressioni nelle prestazioni delle query o nella stabilità del sistema.
Per ottenere il massimo dalle query parallele in PostgreSQL RDS per PostgreSQL, è importante testarle e ottimizzarle in base al carico di lavoro, monitorare l'impatto sul sistema e disabilitare la selezione automatica del piano parallelo a favore del controllo a livello di query.
## Parametri di configurazione
PostgreSQL utilizza diversi parametri per controllare il comportamento e la disponibilità delle query parallele. Comprenderli e ottimizzarli è fondamentale per ottenere prestazioni prevedibili:
| Parametro | Description | Predefinita |
| --- | --- | --- |
| max\$1parallel\$1workers | Numero massimo di processi di lavoro in background che possono essere eseguiti in totale | MASSIMO (\$1 DBInstance VCPU/2,8) |
| max\$1parallel\$1workers\$1per\$1gather | Numero massimo di lavoratori per nodo del piano di interrogazione (ad esempio, per) Gather | 2 |
| parallel\$1setup\$1cost | Costo aggiuntivo del Planner per l'avvio di un'infrastruttura di query parallela | 1000 |
| parallel\$1tuple\$1cost | Costo per tupla elaborata in modalità parallela (influisce sulla decisione del pianificatore) | 0.1 |
| force\$1parallel\$1mode | Forza il pianificatore a testare i piani paralleli (off,on,regress) | off |
### Considerazioni chiave
+ `max_parallel_workers`controlla il pool totale di lavoratori paralleli. Se impostato su un valore troppo basso, alcune query potrebbero tornare all'esecuzione seriale.
+ `max_parallel_workers_per_gather`influisce sul numero di lavoratori che una singola query può utilizzare. Un valore più alto aumenta la concorrenza, ma anche l'utilizzo delle risorse.
+ `parallel_setup_cost`e `parallel_tuple_cost` influiscono sul modello di costo del pianificatore. La riduzione di questi può aumentare le probabilità di scegliere piani paralleli.
+ `force_parallel_mode`è utile per i test ma non deve essere utilizzato in produzione a meno che non sia necessario.
**Nota**
Il valore predefinito del `max_parallel_workers` parametro viene calcolato dinamicamente in base alla dimensione dell'istanza utilizzando la formula`GREATEST($DBInstanceVCPU/2, 8)`. Ciò significa che quando si ridimensiona l' a una dimensione di calcolo maggiore con più vCPUs, il numero massimo di worker paralleli disponibili aumenterà automaticamente. Di conseguenza, le query precedentemente eseguite in modo seriale o con parallelismo limitato possono improvvisamente utilizzare più worker paralleli dopo un'operazione di scalabilità verticale, con conseguenti aumenti imprevisti dell'utilizzo della connessione, dell'utilizzo della CPU e del consumo di memoria. È importante monitorare il comportamento delle query parallele dopo ogni evento di scalabilità del calcolo e, `max_parallel_workers_per_gather` se necessario, apportare modifiche per mantenere un utilizzo prevedibile delle risorse.
## Identifica l'utilizzo delle query parallele
Le query possono passare a piani paralleli basati sulla distribuzione dei dati o sulle statistiche. Esempio:
```
SELECT count(*) FROM customers WHERE last_login < now() - interval '6 months';
```
Questa query potrebbe utilizzare un indice per i dati recenti, ma passare a una scansione sequenziale parallela per i dati storici.
È possibile registrare i piani di esecuzione delle query caricando il `auto_explain` modulo. Per ulteriori informazioni, consulta [Registrazione dei piani di esecuzione delle query](https://aws.amazon.com/premiumsupport/knowledge-center/rds-postgresql-tune-query-performance/#) nel AWS Knowledge Center.
È possibile monitorare gli eventi di attesa relativi a [CloudWatch Database Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights-Database-Instance-Dashboard.html) for Parallel Query. Per ulteriori informazioni sugli eventi di attesa correlati a Parallel Query, consulta [IPC:Parallel](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-ipc-parallel.html) wait events
Dalla versione 18 di PostgreSQL, puoi monitorare l'attività dei lavoratori paralleli utilizzando nuove colonne in e: [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)
+ `parallel_workers_to_launch`: Numero di lavoratori paralleli previsto per il lancio
+ `parallel_workers_launched`: Numero di lavoratori paralleli effettivamente lanciati
Queste metriche aiutano a identificare le discrepanze tra il parallelismo pianificato e quello effettivo, il che può indicare vincoli di risorse o problemi di configurazione. Usa le seguenti query per monitorare l'esecuzione parallela:
Per le metriche dei lavoratori paralleli a livello di database:
```
SELECT datname, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_database
WHERE datname = current_database();
```
Per le metriche dei lavoratori paralleli a livello di query
```
SELECT query, parallel_workers_to_launch, parallel_workers_launched
FROM pg_stat_statements
ORDER BY parallel_workers_launched;
```
## Come controllare il parallelismo
Esistono diversi modi per controllare il parallelismo delle interrogazioni, ciascuno progettato per scenari e requisiti diversi.
Per disabilitare il parallelismo automatico a livello globale, di [parametri per impostare](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithParamGroups.Modifying.html):
```
max_parallel_workers_per_gather = 0;
```
Per le impostazioni persistenti e specifiche dell'utente, il comando ALTER ROLE consente di impostare parametri che verranno applicati a tutte le sessioni future per un determinato utente.
Esempio:
`ALTER ROLE username SET max_parallel_workers_per_gather = 4;`assicura che ogni volta che questo utente si connette al database, le sue sessioni utilizzeranno questa impostazione parallel worker quando richiesto.
Il controllo a livello di sessione può essere ottenuto utilizzando il comando SET, che modifica i parametri per la durata della sessione corrente del database. Ciò è particolarmente utile quando è necessario modificare temporaneamente le impostazioni senza influire sugli altri utenti o sulle sessioni future. Una volta impostati, questi parametri rimangono validi fino al ripristino esplicito o fino al termine della sessione. I comandi sono semplici:
```
SET max_parallel_workers_per_gather = 4;
-- Run your queries
RESET max_parallel_workers_per_gather;
```
Per un controllo ancora più granulare, SET LOCAL consente di modificare i parametri per una singola transazione. È ideale quando è necessario regolare le impostazioni per un insieme specifico di query all'interno di una transazione, dopodiché le impostazioni tornano automaticamente ai valori precedenti. Questo approccio aiuta a prevenire effetti indesiderati su altre operazioni all'interno della stessa sessione.
## Diagnosi del comportamento delle interrogazioni parallele
Utilizzare `EXPLAIN (ANALYZE, VERBOSE)` per confermare se una query utilizza l'esecuzione parallela:
+ Cerca nodi come `Gather``Gather Merge`, o`Parallel Seq Scan`.
+ Confronta i piani con e senza parallelismo.
Per disabilitare temporaneamente il parallelismo per il confronto:
```
SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE ;
RESET max_parallel_workers_per_gather;
```
# Utilizzo dei parametri sull'istanza database RDS for PostgreSQL
In alcuni casi, è possibile creare un'istanza database RDS for PostgreSQL senza specificare un gruppo di parametri personalizzato. In tal caso, l'istanza database viene creata utilizzando il gruppo di parametri di default per la versione di PostgreSQL scelta. Ad esempio, supponiamo di creare un'istanza database RDS for PostgreSQL utilizzando PostgreSQL 13.3. In questo caso, l'istanza database viene creata utilizzando i valori nel gruppo di parametri per le versioni di PostgreSQL 13, `default.postgres13`.
Puoi anche creare i tuoi gruppi di parametri del database personalizzati. È necessario farlo se vuoi modificare qualsiasi impostazione per l'istanza database RDS for PostgreSQL rispetto ai valori predefiniti. Per scoprire come, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md).
Puoi monitorare le impostazioni sull'istanza database RDS for PostgreSQL in diversi modi. Puoi utilizzare l' Console di gestione AWS AWS CLI, the o l'API Amazon RDS. Puoi anche eseguire query sui valori dalla tabella `pg_settings` di PostgreSQL della tua istanza, come illustrato di seguito.
```
SELECT name, setting, boot_val, reset_val, unit
FROM pg_settings
ORDER BY name;
```
Per ulteriori informazioni sui valori restituiti da questa query, consulta [https://www.postgresql.org/docs/current/view-pg-settings.html](https://www.postgresql.org/docs/current/view-pg-settings.html) nella documentazione di PostgreSQL.
Presta particolare attenzione quando modifichi le impostazioni `max_connections` e `shared_buffers` sull'istanza database RDS for PostgreSQL. Supponiamo, ad esempio, di modificare le impostazioni per `max_connections` o `shared_buffers` e di utilizzare valori troppo alti per il carico di lavoro effettivo. In questo caso, l'istanza database RDS for PostgreSQL non verrà avviata. In tal caso, viene visualizzato un errore simile al seguente in `postgres.log`:
```
2018-09-18 21:13:15 UTC::@:[8097]:FATAL: could not map anonymous shared memory: Cannot allocate memory
2018-09-18 21:13:15 UTC::@:[8097]:HINT: This error usually means that PostgreSQL's request for a shared memory segment
exceeded available memory or swap space. To reduce the request size (currently 3514134274048 bytes), reduce
PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
```
Tuttavia, non puoi modificare alcun valore delle impostazioni contenute nei gruppi parametri del database RDS for PostgreSQL di default. Per modificare le impostazioni per qualsiasi parametro, crea innanzitutto un gruppo parametri del database personalizzato. Quindi modifica le impostazioni di tale gruppo personalizzato e applica il gruppo di parametri personalizzato all'istanza database RDS for PostgreSQL. Per ulteriori informazioni, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md).
Esistono due tipi di parametri in RDS per PostgreSQL.
+ **Parametri statici**: i parametri statici richiedono che l'istanza database RDS for PostgreSQL venga riavviata dopo una modifica in modo che il nuovo valore possa avere effetto.
+ **Parametri dinamici**: i parametri dinamici non richiedono un riavvio dopo aver modificato le impostazioni.
**Nota**
Se l'istanza database di RDS for PostgreSQL utilizza il gruppo parametri del database personalizzato, puoi modificare i valori dei parametri dinamici sull'istanza database in esecuzione. Puoi farlo utilizzando l' Console di gestione AWS, the o l' AWS CLI API Amazon RDS.
Se disponi dei privilegi per farlo, puoi anche modificare i valori dei parametri utilizzando i comandi `ALTER DATABASE`, `ALTER ROLE` e `SET`.
## Elenco dei parametri dell'istanza database di RDS for PostgreSQL
Nella tabella seguente sono elencati alcuni dei parametri disponibili in un'istanza database di RDS for PostgreSQL. Per visualizzare tutti i parametri disponibili, usa il [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) AWS CLI comando. Ad esempio, per ottenere l'elenco di tutti i parametri disponibili nel gruppo di parametri predefinito per RDS per PostgreSQL versione 13, esegui il seguente comando.
```
aws rds describe-db-parameters --db-parameter-group-name default.postgres13
```
Puoi anche utilizzare la console. Seleziona **Parameter groups** (Gruppi di parametri) nel menu di Amazon RDS, quindi scegli il gruppo di parametri tra quelli disponibili nella tua Regione AWS.
| Nome del parametro | Apply\$1Type | Descrizione |
| --- | --- | --- |
| `application_name` | Dinamico | Imposta il nome dell'applicazione da riportare nelle statistiche e nei registri. |
| `archive_command` | Dinamico | Imposta il comando shell che verrà chiamato per archiviare un file WAL. |
| `array_nulls` | Dinamico | Abilita l'inserimento di elementi NULL negli array. |
| `authentication_timeout` | Dinamico | Imposta il tempo massimo concesso per completare l'autenticazione del client. |
| `autovacuum` | Dinamico | Avvia il sottoprocesso autovacuum. |
| `autovacuum_analyze_scale_factor` | Dinamico | Numero di inserti, aggiornamenti o eliminazioni di tupla prima di analizzare come una frazione di reltuple. |
| `autovacuum_analyze_threshold` | Dinamico | Numero minimo di inserti, aggiornamenti o eliminazioni di tupla prima di analizzare. |
| `autovacuum_freeze_max_age` | Statico | Età nella quale eseguire l'autovacuum in una tabella per impedire il wraparound ID della transazione. |
| `autovacuum_naptime` | Dinamico | Periodo di inattività tra le esecuzioni di autovacuum. |
| `autovacuum_max_workers` | Statico | Imposta il numero massimo di processi dipendenti di autovacuum in esecuzione simultanea |
| `autovacuum_vacuum_cost_delay` | Dinamico | Ritardo del costo del vacuum, in millisecondi, per l'autovacuum. |
| `autovacuum_vacuum_cost_limit` | Dinamico | Quantità del costo del vacuum disponibile prima del napping, per l'autovacuum. |
| `autovacuum_vacuum_scale_factor` | Dinamico | Numero di aggiornamenti o eliminazioni di tupla prima del vacuum come una frazione di reltuple. |
| `autovacuum_vacuum_threshold` | Dinamico | Numero minimo di aggiornamenti o eliminazioni di tupla prima del vacuum. |
| `backslash_quote` | Dinamico | Imposta se una barra rovesciata (\$1) è consentita nelle stringhe letterali. |
| `bgwriter_delay` | Dinamico | Tempo di inattività della scrittura di sfondo tra i round. |
| `bgwriter_lru_maxpages` | Dinamico | Numero massimo di scrittura di sfondo delle pagine LRU da ripulire per round. |
| `bgwriter_lru_multiplier` | Dinamico | Multiplo dell'uso medio del buffer da liberare per round. |
| `bytea_output` | Dinamico | Imposta il formato di output per byte. |
| `check_function_bodies` | Dinamico | Controlla i corpi delle funzioni durante CREATE FUNCTION. |
| `checkpoint_completion_target` | Dinamico | Tempo trascorso a ripulire i buffer sporchi durante il checkpoint, come una frazione dell'intervallo di checkpoint. |
| `checkpoint_segments` | Dinamico | Imposta la distanza massima nei segmenti di registro tra i checkpoint WAL (write-ahead log) automatici. |
| `checkpoint_timeout` | Dinamico | Imposta il tempo massimo tra i checkpoint WAL automatici. |
| `checkpoint_warning` | Dinamico | Abilita gli avvisi se i segmenti del checkpoint sono riempiti più frequentemente di così. |
| `client_connection_check_interval` | Dinamico | Imposta l'intervallo di tempo tra i controlli di disconnessione durante l'esecuzione di query. |
| `client_encoding` | Dinamico | Imposta la codifica dell'impostazione del carattere del client. |
| `client_min_messages` | Dinamico | Imposta i livelli dei messaggi che vengono inviati al client. |
| `commit_delay` | Dinamico | Imposta il ritardo in microsecondi tra il commit della transazione e la pulizia del WAL su disco. |
| `commit_siblings` | Dinamico | Imposta le transazioni aperte simultanee minime prima di eseguire commit\$1delay. |
| `constraint_exclusion` | Dinamico | Consente al pianificatore di utilizzare i vincoli per ottimizzare le query. |
| `cpu_index_tuple_cost` | Dinamico | Imposta la stima del pianificatore del costo di elaborazione di ciascuna voce di indice durante una scansione dell'indice. |
| `cpu_operator_cost` | Dinamico | Imposta la stima del pianificatore del costo di elaborazione di ciascuna chiamata dell'operatore o della funzione. |
| `cpu_tuple_cost` | Dinamico | Imposta la stima del pianificatore del costo di elaborazione di ciascuna tupla (riga). |
| `cursor_tuple_fraction` | Dinamico | Imposta la stima del pianificatore della frazione delle righe del cursore che verranno recuperate. |
| `datestyle` | Dinamico | Imposta il formato del display per i valori di data e ora. |
| `deadlock_timeout` | Dinamico | Imposta il tempo di attesa su un lock prima di verificare il deadlock. |
| `debug_pretty_print` | Dinamico | I trattini analizzano e visualizzano le visualizzazioni dell'albero. |
| `debug_print_parse` | Dinamico | Registra ogni albero di analisi della query. |
| `debug_print_plan` | Dinamico | Registra ogni programma di esecuzione della query. |
| `debug_print_rewritten` | Dinamico | Registra ogni albero di analisi riscritto della query. |
| `default_statistics_target` | Dinamico | Imposta la destinazione della statistica predefinita. |
| `default_tablespace` | Dinamico | Imposta il tablespace predefinito per la creazione di tabelle e indici. |
| `default_transaction_deferrable` | Dinamico | Imposta lo stato differibile predefinito delle nuove transazioni. |
| `default_transaction_isolation` | Dinamico | Imposta il livello di isolamento della transazione di ogni nuova transazione. |
| `default_transaction_read_only` | Dinamico | Imposta lo stato di sola lettura predefinito delle nuove transazioni. |
| `default_with_oids` | Dinamico | Per impostazione predefinita, crea nuove tabelle con object IDs (OIDs). |
| `effective_cache_size` | Dinamico | Imposta l'ipotesi del pianificatore sulla dimensione della cache del disco. |
| `effective_io_concurrency` | Dinamico | Numero di richieste simultanee che possono essere gestite in modo efficace dal sottosistema del disco. |
| `enable_bitmapscan` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di scansione bitmap. |
| `enable_hashagg` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di aggregazione hash. |
| `enable_hashjoin` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di unione hash. |
| `enable_indexscan` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di scansione dell'indice. |
| `enable_material` | Dinamico | Abilita l'utilizzo da parte del pianificatore della materializzazione. |
| `enable_mergejoin` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di unione. |
| `enable_nestloop` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di unione a ciclo nested. |
| `enable_seqscan` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di scansione sequenziali. |
| `enable_sort` | Dinamico | Abilita l'utilizzo da parte del pianificatore di passaggi di ordinamento espliciti. |
| `enable_tidscan` | Dinamico | Abilita l'utilizzo da parte del pianificatore di piani di scansione TID. |
| `escape_string_warning` | Dinamico | Avvisa circa la perdita di barre rovesciate (\$1) nelle stringhe letterali ordinarie. |
| `extra_float_digits` | Dinamico | Imposta il numero di cifre visualizzate per i valori del punto variabile. |
| `from_collapse_limit` | Dinamico | Imposta la dimensione dell'elenco FROM oltre la quale le sottoquery non vengono compresse. |
| `fsync` | Dinamico | Forza la sincronizzazione degli aggiornamenti sul disco. |
| `full_page_writes` | Dinamico | Scrive pagine intere su WAL quando viene modificato per la prima volta dopo un checkpoint. |
| `geqo` | Dinamico | Abilita l'ottimizzazione genetica delle query. |
| `geqo_effort` | Dinamico | GEQO: lo sforzo viene utilizzato per impostare il valore predefinito per altri parametri GEQO. |
| `geqo_generations` | Dinamico | GEQO: numero di iterazioni dell'algoritmo. |
| `geqo_pool_size` | Dinamico | GEQO: numero di individui nella popolazione. |
| `geqo_seed` | Dinamico | GEQO: seme per la selezione casuale del percorso. |
| `geqo_selection_bias` | Dinamico | GEQO: pressione selettiva all'interno della popolazione. |
| `geqo_threshold` | Dinamico | Imposta la soglia degli elementi FROM oltre i quali viene utilizzato GEQO. |
| `gin_fuzzy_search_limit` | Dinamico | Imposta il risultato massimo consentito per la ricerca esatta da GIN. |
| `hot_standby_feedback` | Dinamico | Determina se un hot standby invia messaggi di feedback allo standby principale o upstream. |
| `intervalstyle` | Dinamico | Imposta il formato del display per i valori dell'intervallo. |
| `join_collapse_limit` | Dinamico | Imposta la dimensione dell'elenco FROM oltre la quale i costrutti JOIN non vengono appiattiti. |
| `lc_messages` | Dinamico | Imposta la lingua nella quale vengono visualizzati i messaggi. |
| `lc_monetary` | Dinamico | Imposta l'ambientazione per la formattazione degli importi monetari. |
| `lc_numeric` | Dinamico | Imposta l'ambientazione per la formattazione degli numeri. |
| `lc_time` | Dinamico | Imposta l'ambientazione per la formattazione dei valori di data e ora. |
| `log_autovacuum_min_duration` | Dinamico | Imposta il tempo minimo di esecuzione al di sopra del quale verranno registrate le azioni di autovacuum. |
| `log_checkpoints` | Dinamico | Registra ogni checkpoint. |
| `log_connections` | Dinamico | Registra ogni connessione riuscita. |
| `log_disconnections` | Dinamico | Registra la fine di una sessione, compresa la durata. |
| `log_duration` | Dinamico | Registra la durata di ogni istruzione SQL completata. |
| `log_error_verbosity` | Dinamico | Imposta la verbosità dei messaggi registrati. |
| `log_executor_stats` | Dinamico | Scrive le statistiche sulla prestazione degli esecutori nel registro del server. |
| `log_filename` | Dinamico | Imposta il modello del nome del file per i file di registro. |
| `log_file_mode` | Dinamico | Imposta le autorizzazioni file per i file di registro. Il valore predefinito è 0644. |
| `log_hostname` | Dinamico | Registra il nome host nei registri delle connessioni. A partire da PostgreSQL 12 e versioni successive, questo parametro è "disattivato" per impostazione predefinita. Quando è attivato, la connessione utilizza la ricerca inversa del DNS per ottenere il nome host che viene acquisito nei log delle connessioni. Se attivi questo parametro, è necessario monitorare l'impatto che ha sul tempo necessario per stabilire le connessioni. |
| `log_line_prefix ` | Dinamico | Controlla le informazioni con prefisso su ciascuna riga di registro. |
| `log_lock_waits` | Dinamico | Registra lunghe attese di lock. |
| `log_min_duration_statement` | Dinamico | Imposta il tempo minimo di esecuzione al di sopra del quale verranno registrate le istruzioni. |
| `log_min_error_statement` | Dinamico | Fa sì che tutte le istruzioni che generano un errore pari o superiore a questo livello vengano registrate. |
| `log_min_messages` | Dinamico | Imposta i livelli dei messaggi che vengono registrati. |
| `log_parser_stats` | Dinamico | Scrive le statistiche sulla prestazione del decodificatore nel registro del server. |
| `log_planner_stats` | Dinamico | Scrive le statistiche sulla prestazione del programmatore nel registro del server. |
| `log_rotation_age` | Dinamico | La rotazione del file di registro automatico avverrà dopo N minuti. |
| `log_rotation_size` | Dinamico | La rotazione del file di registro automatico avverrà dopo N kilobyte. |
| `log_statement` | Dinamico | Imposta il tipo di istruzioni registrate. |
| `log_statement_stats` | Dinamico | Scrive le statistiche cumulative sulla prestazione nel registro del server. |
| `log_temp_files` | Dinamico | Registra l'uso di file temporanei più grandi di questo numero di kilobyte. |
| `log_timezone` | Dinamico | Imposta il fuso orario da utilizzare nei messaggi di registro. |
| `log_truncate_on_rotation` | Dinamico | Tronca i file di log esistenti con lo stesso nome durante la rotazione del registro. |
| `logging_collector` | Statico | Avvia un sottoprocesso per acquisire i and/or csvlogs di output di stderr in file di registro. |
| `maintenance_work_mem` | Dinamico | Imposta la memoria massima da utilizzare per le operazioni di manutenzione. |
| `max_connections` | Statico | Imposta il numero massimo di connessioni simultanee. |
| `max_files_per_process` | Statico | Imposta il numero massimo di file aperti in modo simultaneo per ogni processo del server. |
| `max_locks_per_transaction` | Statico | Imposta il numero massimo di lock per transazione. |
| `max_pred_locks_per_transaction` | Statico | Imposta il numero massimo di lock del predicato per transazione. |
| `max_prepared_transactions` | Statico | Imposta il numero massimo di transazioni preparati in modo simultaneo. |
| `max_stack_depth` | Dinamico | Imposta la profondità di stack massima in kilobyte. |
| `max_standby_archive_delay` | Dinamico | Imposta il ritardo massimo prima di annullare le query quando un server hot standby elabora i dati WAL archiviati. |
| `max_standby_streaming_delay` | Dinamico | Imposta il ritardo massimo prima di annullare le query quando un server hot standby elabora i dati WAL in streaming. |
| max\$1wal\$1size | Dinamico | Imposta la dimensione WAL (MB) che attiva un punto di controllo. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Parameters.html) Utilizza il comando seguente sull’istanza database Amazon RDS per PostgreSQL per visualizzare il valore corrente: SHOW max_wal_size;
|
| min\$1wal\$1size | Dinamico | Imposta la dimensione minima di contrazione di WAL. Per PostgreSQL versione 9.6 e precedenti, min\$1wal\$1size è nelle unità di 16 MB. Per PostgreSQL versione 10 e successive, min\$1wal\$1size è nelle unità di 1 MB. |
| `quote_all_identifiers` | Dinamico | Aggiunge virgolette (") a tutti gli identificatori quando si generano i frammenti SQL. |
| `random_page_cost` | Dinamico | Imposta la stima del pianificatore del costo di una pagina del disco recuperata in modo non sequenziale. Questo parametro non ha valore a meno che non sia attivata la gestione del piano di query. Quando la gestione del piano di query è attiva, il valore di default per questo parametro è 4. |
| rds.adaptive\$1autovacuum | Dinamico | Regola in modo automatico i parametri di autovacuum ogni qualvolta la soglia dell’ID di transazione venga superata. |
| rds.force\$1ssl | Dinamico | Richiede l'uso di connessioni SSL. Il valore predefinito è impostato su 1 (on) per RDS per PostgreSQL versione 15. Tutti gli altri database RDS per PostgreSQL versione principale 14 e precedenti hanno il valore predefinito impostato su 0 (off). |
| `rds.local_volume_spill_enabled` | Statico | Consente la scrittura di file di versamento logici sul volume locale. |
| `rds.log_retention_period` | Dinamico | Imposta la conservazione dei registri in modo che Amazon RDS elimini i registri PostgreSQL più vecchi di n minuti. |
| rds.rds\$1superuser\$1reserved\$1connections | Statico | Imposta il numero di slot di connessione riservati a rds\$1superusers. Questo parametro è disponibile solo nelle versioni 15 e precedenti. Per maggiori informazioni, consulta la documentazione di PostgreSQL [reserved\$1connections](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-RESERVED-CONNECTIONS). |
| `rds.replica_identity_full` | Dinamico | Quando impostato su `on`, questo parametro sostituisce l’impostazione dell’identità di replica su `FULL` per tutte le tabelle del database. Ciò significa che tutti i valori delle colonne vengono scritti nel WAL (Write Ahead Log), indipendentemente dalle impostazioni `REPLICA IDENTITY FULL`. L’abilitazione di questo parametro può aumentare gli IOPS dell’istanza database a causa della registrazione di log WAL aggiuntiva. |
| rds.restrict\$1password\$1commands | Statico | Limita chi può gestire le password per gli utenti con il ruolo rds\$1password. Impostare questo parametro a 1 per abilitare la limitazione per la password. Il valore predefinito è 0. |
| `search_path` | Dinamico | Imposta l'ordine di ricerca dello schema per i nomi che non sono qualificati come schema. |
| `seq_page_cost` | Dinamico | Imposta la stima del pianificatore del costo di una pagina del disco recuperata in modo sequenziale. |
| `session_replication_role` | Dinamico | Imposta il comportamento delle sessioni per i trigger e le regole di riscrittura. |
| `shared_buffers` | Statico | Imposta il numero di buffer di memoria condivisa utilizzati dal server. |
| `shared_preload_libraries ` | Statico | Elenca le librerie condivise da precaricare nell'istanza database di RDS per PostgreSQL. I valori supportati includono auto\$1explain, orafce, pgaudit, pglogical, pg\$1bigm, pg\$1cron, pg\$1hint\$1plan, pg\$1prewarm, pg\$1similarity, pg\$1stat\$1statements, pg\$1tle, pg\$1transport, plprofiler e plrust. |
| `ssl` | Dinamico | Abilita le connessioni SSL. |
| `sql_inheritance` | Dinamico | Fa sì che le sottotabelle vengano incluse per impostazione predefinita in vari comandi. |
| `ssl_renegotiation_limit` | Dinamico | Imposta la quantità di traffico da inviare e ricevere prima di rinegoziare le chiavi di crittografia. |
| `standard_conforming_strings` | Dinamico | Fa sì che le stringhe ... trattino letteralmente le barre rovesciate. |
| `statement_timeout` | Dinamico | Imposta la durata massima concessa di ogni istruzione. |
| `synchronize_seqscans` | Dinamico | Abilita le scansioni sequenziali sincronizzate. |
| `synchronous_commit` | Dinamico | Imposta il livello di sincronizzazione delle transazioni correnti. |
| `tcp_keepalives_count` | Dinamico | Numero massimo di ritrasmissioni keepalive TCP. |
| `tcp_keepalives_idle` | Dinamico | Tempo tra l'emissione di keepalive TCP. |
| `tcp_keepalives_interval` | Dinamico | Tempo tra la ritrasmissione di keepalive TCP. |
| `temp_buffers` | Dinamico | Imposta il numero massimo di buffer temporanei utilizzati da ogni sessione. |
| temp\$1file\$1limit | Dinamico | Imposta la dimensione massima in KB fino a cui i file temporanei possono crescere. |
| `temp_tablespaces` | Dinamico | Imposta i tablespace da usare per le tabelle temporanee e i file di ordinamento. |
| `timezone` | Dinamico | Imposta il fuso orario per la visualizzazione e l'interpretazione dei timestamp. Internet Assigned Numbers Authority (IANA) pubblica nuovi fusi orari all'indirizzo [https://www.iana.org/time-zones](https://www.iana.org/time-zones) più volte all'anno. Ogni volta che RDS rilascia una nuova versione di manutenzione secondaria di PostgreSQL, la versione viene fornita con i dati sul fuso orario più recenti al momento del rilascio. Quando utilizzi le versioni più recenti di RDS per PostgreSQL, hai a disposizione i dati recenti relativi ai fusi orari di RDS. Per assicurarti che l'istanza database disponga dei dati più aggiornati relativi ai fusi orari, ti consigliamo di eseguire l'aggiornamento a una versione successiva del motore di database. Non è possibile modificare manualmente le tabelle dei fusi orari nelle istanze database di PostgreSQL. RDS non modifica né ripristina i dati dei fusi orari delle istanze database in esecuzione. I nuovi dati dei fusi orari vengono installati solo quando si esegue un aggiornamento della versione del motore di database. |
| `track_activities` | Dinamico | Raccoglie informazioni sull'esecuzione dei comandi. |
| `track_activity_query_size` | Statico | Imposta la dimensione riservata per pg\$1stat\$1activity.current\$1query, in byte. |
| `track_counts` | Dinamico | Raccoglie statistiche sull'attività del database. |
| `track_functions` | Dinamico | Raccoglie statistiche a livello di funzione sull'attività del database. |
| `track_io_timing` | Dinamico | Raccoglie statistiche temporali sull'attività del database. I/O |
| `transaction_deferrable` | Dinamico | Indica se rinviare una transazione serializzabile di sola lettura fino a quando non può essere eseguita senza possibili errori di serializzazione. |
| `transaction_isolation` | Dinamico | Imposta il livello di isolamento delle transazioni attuali. |
| `transaction_read_only` | Dinamico | Imposta lo stato di sola lettura delle transazioni attuali. |
| `transform_null_equals` | Dinamico | Tratta expr=NULL come expr È NULL. |
| `update_process_title` | Dinamico | Aggiorna il titolo del processo per mostrare il comando SQL attivo. |
| `vacuum_cost_delay` | Dinamico | Ritardo del costo del vacuum, in millisecondi. |
| `vacuum_cost_limit` | Dinamico | Quantità del costo del vacuum disponibile prima del napping. |
| `vacuum_cost_page_dirty` | Dinamico | Costo del vacuum per una pagina sporcata dal vacuum. |
| `vacuum_cost_page_hit` | Dinamico | Costo del vacuum per una pagina trovata nella cache del buffer. |
| `vacuum_cost_page_miss` | Dinamico | Costo del vacuum per una non pagina trovata nella cache del buffer. |
| `vacuum_defer_cleanup_age` | Dinamico | Numero di transazioni in base alle quali il vacuum e la pulizia a caldo devono essere posticipati, se presenti. |
| `vacuum_freeze_min_age` | Dinamico | Età minima in cui il vacuum dovrebbe congelare una riga della tabella. |
| `vacuum_freeze_table_age` | Dinamico | Età in cui il vacuum dovrebbe eseguire la scansione di un'intera tabella per congelare le tuple. |
| `wal_buffers` | Statico | Imposta il numero di buffer della pagina del disco nella memoria condivisa per WAL. |
| `wal_writer_delay` | Dinamico | Tempo di inattività della scrittura WAL tra i flush di WAL. |
| `work_mem` | Dinamico | Imposta la memoria massima da utilizzare per gli spazi di lavoro delle query. |
| `xmlbinary` | Dinamico | Imposta come i valori binari devono essere codificati in XML. |
| `xmloption` | Dinamico | Imposta se i dati XML nelle operazioni di analisi e serializzazione implicite devono essere considerati come documenti o frammenti di contenuto. |
Amazon RDS usa le unità PostgreSQL predefinite per tutti i parametri. La tabella seguente mostra l'unità predefinita di PostgreSQL per ogni parametro.
| Nome del parametro | Unità |
| --- | --- |
| `archive_timeout` | s |
| `authentication_timeout` | s |
| `autovacuum_naptime` | s |
| `autovacuum_vacuum_cost_delay` | ms |
| `bgwriter_delay` | ms |
| `checkpoint_timeout` | s |
| `checkpoint_warning` | s |
| `deadlock_timeout` | ms |
| `effective_cache_size` | 8 KB |
| `lock_timeout` | ms |
| `log_autovacuum_min_duration` | ms |
| `log_min_duration_statement` | ms |
| `log_rotation_age` | minuti |
| `log_rotation_size` | KB |
| `log_temp_files` | KB |
| `maintenance_work_mem` | KB |
| `max_stack_depth` | KB |
| `max_standby_archive_delay` | ms |
| `max_standby_streaming_delay` | ms |
| `post_auth_delay` | s |
| `pre_auth_delay` | s |
| `segment_size` | 8 KB |
| `shared_buffers` | 8 KB |
| `statement_timeout` | ms |
| `ssl_renegotiation_limit` | KB |
| `tcp_keepalives_idle` | s |
| `tcp_keepalives_interval` | s |
| `temp_file_limit` | KB |
| `work_mem` | KB |
| `temp_buffers` | 8 KB |
| `vacuum_cost_delay` | ms |
| `wal_buffers` | 8 KB |
| `wal_receiver_timeout` | ms |
| `wal_segment_size` | B |
| `wal_sender_timeout` | ms |
| `wal_writer_delay` | ms |
| `wal_receiver_status_interval` | s |