Gli eseguibili di PostgreSQL
Le locazioni degli eseguibili di PostgreSQL cambiano in funzione della modalità di installazione e del sistema operativo scelto per ospitarlo.
Nel caso di un’installazione binaria su sistema debian questi vengono posizionati nella directory /usr/bin.
Nel caso di un’installazione da sorgenti, se il configure è stato lanciato senza specificare il PREFIX allora gli eseguibili vengono posizionati nella directory /usr/local/pgsql/bin.
In questo caso particolare, la directory /usr/local/pgsql ospita l’intera struttura di eseguibili, documentazione, librerie ed eventuali moduli contrib.
Pertanto il percorso degli eseguibili, per maggiore comodità d’uso da riga di comando, va aggiunto al PATH del nostro sistema.
In genere si preferisce editare il file /etc/profile per avere una mappatura automatica oppure, se non si ha accesso come utente root al sistema si può modificare il file .bash_profile della home dell’utente postgres.
Sui sistemi windows invece l’installazione crea nella cartella c:postgresPostgreSQLXXX l’intera struttura con directory bin contenente gli eseguibili e Data contenente il cluster, se questi è stato creato contestualmente all’installazione.
Passiamo quindi ad analizzarli nel dettaglio.
postgres
postgres è il server PostgreSQL.
Ogni volta che un client si collega, in maniera locale oppure via tcp, l’istanza postgres avvia un nuovo processo server che prende in carico la connessione.
È possibile avere solo un’istanza postgres per un database cluster.
Questi è una directory dedicata, chiamata normalmente «data area», che contiene tutti i database associati all’instanza postgres.
E possibile avere più istanze postgres sullo stesso sistema a patto di avere data area differenziate e porte d’ascolto TCP diverse.
Quando postgres viene lanciato, come comando oppure con pg_ctl, deve conoscere la posizione della data area.
Il parametro da riga di comando -D oppure la variabile d’ambiente PGDATA devono quindi essere definite affinchè postmaster possa partire.
Per ragioni puramente pratiche è preferibile definire PGDATA al momento del login utente in modo da rendere disponibile questa informazione a postgres e ai programmi che devono conoscere la posizione della data area, come initdb e pg_ctl.
Per ragioni storiche è presente l’alias postmaster che punta all’eseguibile postgres
psql
psql è il terminale interattivo di PostgreSQL.
Permette di inviare query in modalità interattiva, permette di salvare l’output su file e di leggere file sql.
Per tale motivo è lo strumento principale per il restore da dump sql.
Se viene ricompilato con le funzionalità readline permette di lavorare in maniera del tutto simile alla bash.
clusterdb
L’eseguibile clusterdb è un wrapper per il comando SQL CLUSTER.
Semplicemente opera un recluster di tutte le tabelle nel database bersaglio.
È possibile specificare quale tabella sottoporre a clusterizzazione.
createdb
createdb crea un nuovo database nel cluster.
L’eseguibile e’ un wrapper per il comando SQL CREATE DATABASE
L’utente di database che esegue il comando diventa l’owner del nuovo database.
È possibile specificare un owner diverso con l’opzione -O.
createlang
createlang crea un nuovo linguaggio nel database bersaglio.
L’eseguibile e’ un wrapper per il comando SQL CREATE LANGUAGE
createuser
createuser crea un nuovo ruolo utente nel cluster PostgreSQL.
Solo gli utenti con la grant CREATEROLE possono creare nuovi utenti.
createuser è un wrapper per il comando SQL CREATE ROLE .
dropdb
dropdb distrugge un database presente nel cluster PostgreSQL.
L’utente per eseguire il comando dropdb deve essere superutente oppure owner del database da cancellare.
dropdb è un wrapper SQL del comando DROP DATABASE.
droplang
droplang elimina un linguaggio procedurale nel database bersaglio.
È consigliabile adoperare droplang per la cancellazione poiché questo comando esegue una serie di controlli che altrimenti andrebbero fatti a mano.
dropuser
dropuser è un wrapper da riga di comando per il comando SQL DROP USER.
ecpg
ecpg è il preprocessore C con comandi SQL embedded.
Sostanzialmente converte i programmi scritti in C aventi comandi SQL in codice C sostituendo ai comandi SQL chiamate a funzioni specifiche per l’elaborazione SQL.
Il file sorgente prodotto da ecpg può essere elaborato da un qualsiasi compilatore C.
ecpg trasforma qualsiasi file specificato dalla riga di comando nel corrispondente nome file con estensione .c .
L’estensione di input preferita da ecpg è .pgc a indicare che si tratta di file specifici per l’ecpg.
Qualora il file avesse estensione diversa da .pgc allora ecpg produce un file di output con l’intero nome file, comprensivo di estensione, con l’aggiunta di .c in fondo.
Il nome del file di output può essere specificato usando l’opzione -o.
initdb
initdb crea un nuovo cluster PostgreSQL.
Un cluster è una collezione di database gestiti da una singola istanza server.
Il programma produce, in una directory specifica, che può essere indicata da riga di comando oppure attraverso la variabile d’ambiente PGDATA, una serie di sottodirectory.
La struttura di queste directory le vedremo in dettaglio nel capitolo 10.
La creazione del cluster genera il catalogo di sistema, le directory che andranno ad ospitare i file specifici dell’istanza PostgreSQL e i due database template0 e template1.
Il database template0 è il database master di template1 ed ha la peculiarità di non essere accedibile in alcun modo.
Il database template1 viene prodotto copiando template0 su di una nuova directory oggetto e da questi, dalla versione 8.1 in poi, viene generato il database postgres.
Ogni volta che si va a generare un nuovo database con il comando createdb o con CREATE DATABASE, se non viene indicato il template di partenza allora viene adoperato template1 come master per la creazione.
È quindi consigliato apportare le modifiche che si vogliono propagare ai nuovi database, come ad esempio un linguaggio procedurale specifico, al template1 prima di iniziare a creare nuovi database.
Ovviamente le modifiche fatte a template1 si propagano solo ai nuovi database, quelli già presenti vanno editati a mano.
inidb deve essere lanciato con l’utente di sistema che andrà a gestire il processo postgres.
Inoltre iniddb inizializza il default locale e character set encoding del cluster database.
La collation order e il character set sono fissi e non possono essere modificati.
Ordini di collation diversi da C e POSIX possono dare decadimenti di performance.
Diventa quindi strategico scegliere il locale corretto prima di lanciare initdb.
Un diverso character set può essere definito durante la creazione di un nuovo database con l’opzione –encoding di createdb oppure con la clausola ENCODING del corrispondente comando SQL.
ipcclean
ipcclean rimuove tutti i segmenti di memoria condivisa e i semafori dell’utente di sistema che lancia il comando.
Il suo utilizzo è specifico quando avviene un crash di istanza per ripulire la memoria.
Considerato che il rilancio del server effettua una pulizia della memoria, questo comando è abbastanza inutile.
Lanciare questo comando con il server in esecuzione provoca la deallocazione di tutta la memoria condivisa dal processo postgres con serie conseguenze sul server.
pg_config
L’utilità pg_config stampa a video i parametri di configurazione della versione installata di PostgreSQL.
Viene utilizzato per determinare la posizione dei file di header e delle librerie.
pg_controldata
pg_controldata stampa a video le informazioni del processo di inizializzazione del cluster fatto da initdb come versione del catalogo e il locale del server.
Oltre a queste informazioni vengono estratti dati specifici relativi al cluster come ad esempio lo stato dei WAL ed i checkpoint.
pg_ctl
pg_ctl è l’utilità specifica per l’avvio, l’arresto il rilancio e il ricaricamento del server PostgreSQL.
Permette inoltre di interrogare lo status del server in esercizio.
Il suo utilizzo è da preferirsi al lancio manuale del comando postgres in quanto ha delle opzioni specifiche per lo shutdown controllato del server.
pg_dump
pg_dump è lo strumento principale per il backup dei database PostgreSQL.
Esegue backup consistenti all’istante di lancio del comando anche se il cluster è acceduto da più client.
pg_dump, a parte l’overhead sul server, non blocca la normale attività del cluster e può essere lanciato senza rischi di blocchi.
I backup possono essere effettuati sia in formato testo, semplici comandi SQL che vanno a ricreare oggetti e dati, che in formato binario compresso e non.
Il restore dei file di testo avviene con l’invio di questi file al comando psql mentre per il restore dei file binari è necessaria l’utilità pg_restore.
pg_dumpall
pg_dumpall è un wrapper per pg_dump che esegue il backup di tutti i database del cluster su cui è lanciato.
pg_resetxlog
pg_resetxlog rimuove i WAL dalla directory pg_xlog ed eventualmente resetta le informazioni di controllo memorizzate nel file pg_control.
Questo comando va considerato alla stregua di ultima spiaggia in caso di corruzione dei WAL in quanto il reset di questi file cancella ogni riferimento consistente tra i dati disco e lo stato delle transazioni.
In caso di utilizzo di pg_resetxlog una volta riavviata l’istanza va immediatamente eseguito un dump del cluster nella sua interezza con pg_dump, reinizializzato un nuovo cluster con initdb sul quale va reimportato il dump.
Per ragioni di sicurezza pg_resetxlog non accetta la variabile d’ambiente PGDATA ma richiede l’indicazione da riga di comando della directory data.
pg_restore
pg_restore serve a importare un database PostgreSQL esportato in maniera binaria da pg_dump.
reindexdb
reindexdb è un wrapper per il comando SQL REINDEX che effettua la ricostruzione degli indici in un database PostgreSQL.
vacuumdb
vacuumdb è un wrapper per il comando VACUUM che opera il vacuum sui database PostgreSQL.
