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?