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

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

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?

1. avviare pgadmin nel client con un tunnel ssh verso il database
2. sostituito parametro cert_name con conn_name come scritto qui sopra
3. ssh verso l'host
4. screen -S migrazione
5. su - postgres
6. pg_dump -f /var/lib/postgresql/`date “+%s”`_before_wheezy_update.sql.z5 -Fc -Z5 “<nomedb>”

1. Su una installazione con database di 34GB, il dump fatto come sopra si riduce a 905MB!