Migrazione a Postgres 9.x

Per essere sicuri che noi e i nostri clienti migriamo “dolcemente” alla versione 9.x di PostgreSQL:

Leggere le note di release della 9.0: http://www.postgresql.org/docs/9.1/static/release-9-0.html

ATTENZIONE alle incompatibilità in particolare nel linguaggio PG/PLSQL

Al quoting delle stringhe

testare la migrazione

Appunti

Da http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server (tags: postgresql, sysadmin, performance)

9.1+: wal_buffers: default a 3% di shared_buffers e limite massimo (come da versioni precedenti) a 16MB

9.1+: wal_sync_method: algoritmi di selezione automatica su kernel “nuovi”

Da http://wiki.postgresql.org/wiki/Introduction_to_VACUUM,_ANALYZE,_EXPLAIN,_and_COUNT

9.0+: I parametri max_fsm_relations e max_fsm_pages sono settati automaticamente

Da http://wiki.postgresql.org/wiki/VACUUM_FULL

8.4⇐: VACUUM FULL è da evitare! Usare CLUSTER

9.0+: VACUUM FULL va bene

migrazione plt

Nella funzione acs_service.update_chamber_connection abbiamo il parametro cert_name che non si può chiamare come il nome della colonna. Nell'installazione honeywell su server gasistafelice.befair.it l'ho sostituito con conn_name

I trigger nelle nuove versioni di postgres possono esere definiti con una clausola WHEN questo ci potrebbe fare comodo per evitare la chiamata ricorsiva del trigger di compressione?

migrazione

avviare pgadmin nel client con un tunnel ssh verso il database

sostituito parametro cert_name con conn_name come scritto qui sopra

ssh verso l'host

screen -S migrazione

su - postgres

pg_dump -f /var/lib/postgresql/`date “+%s”`_before_wheezy_update.sql.z5 -Fc -Z5 “<nomedb>”