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

# Processi di RDS per PostgreSQL
<a name="PostgreSQL.Tuning.concepts.processes"></a>

RDS per PostgreSQL utilizza più processi.

**Topics**
+ [Processo postmaster](#PostgreSQL.Tuning.concepts.postmaster)
+ [Processi di back-end](#PostgreSQL.Tuning.concepts.backend)
+ [Processi in background](#PostgreSQL.Tuning.concepts.vacuum)

## Processo postmaster
<a name="PostgreSQL.Tuning.concepts.postmaster"></a>

Il *processo postmaster* è il primo processo eseguito quando si avvia RDS per PostgreSQL. Il processo postmaster ha le seguenti responsabilità principali:
+ Forcella e monitoraggio dei processi in background
+ Ricevere le richieste di autenticazione dai processi client e autenticarle prima di consentire al database di servire le richieste

## Processi di back-end
<a name="PostgreSQL.Tuning.concepts.backend"></a>

Se il postmaster autentica una richiesta del cliente, il postmaster forcherà un nuovo processo di back-end, chiamato anche processo postgres. Un processo client si connette esattamente a un processo back-end. Il processo client e il processo di backend comunicano direttamente senza intervento da parte del processo postmaster.

## Processi in background
<a name="PostgreSQL.Tuning.concepts.vacuum"></a>

Il processo postmaster forca diversi processi che eseguono diverse attività di back-end. Alcuni dei più importanti includono quanto segue:
+ Scrittore WAL

  RDS per PostgreSQL scrive i dati nel buffer WAL (write ahead logging) nei file di log. Il principio della registrazione write ahead è che il database non può scrivere modifiche ai file di dati fino a quando il database ha scritto i record di log che descrivono tali modifiche su disco. Il meccanismo WAL riduce l'I/O del disco e consente a RDS per PostgreSQL di utilizzare i log per recuperare il database dopo un errore.
+ Background writer

  Questo processo scrive periodicamente pagine sporche (modificate) dai buffer di memoria ai file di dati. Una pagina diventa sporca quando un processo di back-end la modifica in memoria.
+ Il daemon dell'Autovacuum

  Il daemon include i seguenti elementi:
  + Il lanciatore di autovacuum
  + I processi di autovacuum worker

  Se abilitata, verifica la presenza di tabelle con un numero elevato di tuple inserite, aggiornate o eliminate. Il daemon ha le seguenti responsabilità:
  + Recuperare o riutilizzare lo spazio su disco occupato da righe aggiornate o eliminate
  + Aggiornare le statistiche utilizzate dal planner
  + Proteggere contro la perdita di dati precedenti a causa di un involucro dell'ID transazione

  La funzione autovacuum automatizza l'esecuzione dei comandi `VACUUM` e `ANALYZE`. `VACUUM` ha le seguenti varianti: standard e full. Il vuoto standard funziona in parallelo con altre operazioni di database. `VACUUM FULL` richiede un blocco esclusivo sulla tabella su cui sta lavorando. Pertanto, non può essere eseguito in parallelo con le operazioni che accedono alla stessa tabella. `VACUUM`crea una notevole quantità di I/O traffico, che può causare scarse prestazioni per altre sessioni attive.