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?