Riprendendo le parti essenziali del comunicato ufficiale del rilascio di PostgreSQL 9.3, quest’ultima versione migliora l’affidabilità e la disponibilità di Postgres, nonché la capacità di integrazione con altri database.

PostgreSQL 9.3 aggiunge infatti la capacità di scrittura ai Foreign Data Wrapper, permettendo lo scambio di dati bi-direzionale fra sistemi. I complessi sistemi informativi odierni
coinvolgono più database e fonti di dati semi-strutturati: PostgreSQL ne favorisce
l’integrazione all’interno di un singolo stack, in modo coerente. Il progetto ha
anche rilasciato l’estensione postgres_fdw, un driver ad elevate prestazioni
per federazioni di database PostgreSQL in modalità lettura/scrittura.

Come ogni altro rilascio annuale, PostgreSQL 9.3 include molte funzionalità
in grado di rendere più semplice, più flessibile e più divertente lavorare
con Postgres, sia per sviluppatori di applicazioni, che per amministratori
di sistema e analisti. Fra le principali funzionalità introdotte, si citano:

• Metodi di generazione e di accesso per dati di tipo JSON
• Viste aggiornabili
• pg_dump parallelo per velocizzare backup di database di grandi dimensioni
• Supporto per LATERAL JOIN

Inoltre, la funzionalità “User-Defined Background Worker” consente agli sviluppatori
di scrivere task manager, gestori di richieste, processori paralleli, strumenti per
la gestione di code e altre utilità che permettono a PostgreSQL di coordinare
il lavoro. Un esempio di ciò è Mongres, un background worker che accetta query
per MongoDB, le interpreta e le passa a PostgreSQL.

PostgreSQL 9.3 sarà ovviamente il protagonista principale del PGDay italiano 2013, che si terrà il 25 ottobre prossimo a Prato, e di PGConf.EU, che si terrà a Dublino dal 29 ottobre al 1 novembre prossimi.
2ndQuadrant sarà partner di entrambe le manifestazioni e molti nostri speaker interverranno in quelle occasioni e vi porteranno le novità del nostro DBMS preferito.

Questa versione aggiunge la compatibilità con l’imminente PostgreSQL 9.3. Introduce inoltre il supporto per l’opzione di recovery “–target-name”, che permette di ripristinare l’intero server PostgreSQL ad un preciso istante, precedentemente specificato con un’etichetta tramite pg_create_restore_point (solo per utenti di PostgreSQL 9.1 o superiore).

Barman è stato inoltre rifattorizzato per Python 3. Al momento il supporto è sperimentale, ma incoraggiamo gli utenti Python 3 a provare questa versione ed a farci avere il loro feedback.

Per una lista completa delle modifiche, si faccia riferimento alle note di rilascio nel comunicato ufficiale in lingua inglese.

Sono disponibili per il download:

• Sorgenti
• RPM per RHEL/CentOS 5 (dipendenze)
• RPM per RHEL/CentOS 6 (dipendenze)
• PyPI
• Documentazione (in inglese)

Maggiori informazioni su Barman sono disponibili sul relativo sito all’indirizzo www.pgbarman.org.

Barman è un software open-source progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

PostgreSQL 9.3 rimuove alla radice una comune fonte di problemi all’avvio del server PostgreSQL: l’impostazione della memoria condivisa di sistema, in gergo “System V Shared Memory”.

I problemi sorgono, come è facile aspettarsi, al momento in cui la memoria condivisa da parte di PosgreSQL per la gestione dei buffer (ricordo essere organizzati in pagine di dati in blocchi da 8kB) supera il valore configurato nel kernel del sistema. È possibile modificare il parametro shared_buffers (ad esempio per impostarlo a 1GB) nel file postgresql.conf.

Fino a PostgreSQL 9.2, la modifica del valore shared_buffers di PostgreSQL doveva avvenire unitamente ad una modifica delle impostazioni di memoria condivisa a livello di sistema. Ad esempio, su sistemi Ubuntu 12.04 il valore impostato è ottenibile tramite:

/~$ cat /proc/sys/kernel/shmmax
 33554432

quindi 32MB. Volendo lavorare con una shared_memory di 128MB utilizzando le attuali versioni di PostgreSQL, occorrerebbe impostare tale valore come limite anche nel kernel. Ad esempio in Ubuntu 12.04 una modifica temporanea può essere apportata con il comando sysctl:

/~$ sudo sysctl -w kern.sysv.shmmax=134217728
kern.sysv.shmmax: 33554432 -> 134217728 
/~$ sudo sysctl -w kern.sysv.shmall=134217728
kern.sysv.shmmax: 2097152 -> 134217728

Generalmente i sistemi operativi lavorano con valori di shared memory molto conservativi (32MB nell’esempio visto sopra). Tuttavia, generalmente valori operativi consigliati in PostgreSQL per l’uso della memoria condivisa si attestano sul 20%-25% della RAM disponibile. Per macchine con ad esempio 64GB di RAM, è necessario modificare la shared memory di sistema a valori così elevati. PostgreSQL 9.3 risolve il problema riducendo il consumo di memoria shared tramite l’impiego di mmap.

In questo modo è possibile lavorare con valori di shared_buffers impostati in postgresql.conf superiori alla memoria shared impostata nel sistema. Ad esempio il valore di shared_buffers impostato di default in PostgreSQL 9.3 è pari a 128MB.

Avviando il server PostgreSQL, è possibile osservare la gestione della memoria da parte del sistema con il comando:

ps -u 1000 f u

Il risultato ottenibile è qualcosa di simile al seguente:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1000      3979  0.0  0.1 170836 12828 pts/2    S    16:02   0:00 /home/gbroccolo/pgsql/master/DemoInstall/bin/postgres
1000      3981  0.0  0.0 170836   976 ?        Ss   16:02   0:00  \_ postgres: checkpointer process
1000      3982  0.0  0.0 170836  1764 ?        Ss   16:02   0:00  \_ postgres: writer process
1000      3983  0.0  0.0 170836   972 ?        Ss   16:02   0:00  \_ postgres: wal writer process
1000      3984  0.0  0.0 171588  2292 ?        Ss   16:02   0:00  \_ postgres: autovacuum launcher process
1000      3985  0.0  0.0  26456  1020 ?        Ss   16:02   0:00  \_ postgres: stats collector process

PostgreSQL 9.3 riesce quindi a gestire uno spazio di memoria condivisa più che compatibile con i 128MB richiesti, senza richiedere di agire sulle risorse fornite dal kernel e riducendo la complessità in fase di installazione e configurazione.

PostgreSQL 9.2 ha introdotto il supporto alla memorizzazione all’interno del database di dati di tipo JSON (JavaScript Object Notation), formato ideato per lo scambio di dati in applicazioni client-server. PostgreSQL 9.3 introduce importanti funzioni native per la creazione e la manipolazione di dati JSON, oltre a operatori per l’accesso a informazioni contenute in dati JSON.

Per quanto riguarda la generazione di valori JSON, PostgreSQL 9.3 introduce due funzioni:

• to_json(anyelement): converte un valore in JSON, utilizzando il casting oppure la rappresentazione testuale a seconda del tipo di dato
• json_agg(record): aggrega un set di record come un array di oggetti JSON

Il seguente esempio mostra la funzione to_json, visualizzando la serie dei primi 10 numeri interi e il rispettivo quadrato tramite una query WITH:

WITH a AS (
 SELECT n, n^2 AS q FROM generate_series(1, 10) n
)
SELECT to_json(a) AS json FROM a;

Il risultato è un insieme di record (10 per la precisione), ciascuno rappresentato da un oggetto JSON composto da due membri con chiave n e q:

       json
------------------
 {"n":1,"q":1}
 {"n":2,"q":4}
 {"n":3,"q":9}
 {"n":4,"q":16}
 {"n":5,"q":25}
 {"n":6,"q":36}
 {"n":7,"q":49}
 {"n":8,"q":64}
 {"n":9,"q":81}
 {"n":10,"q":100}
(10 rows)

Il successivo esempio applica la funzione aggregata json_agg, alla query precedente:

WITH a AS (
 SELECT n, n^2 AS q FROM generate_series(1, 10) n
)
SELECT json_agg(a) AS json FROM a;

Il risultato è una rappresentazione sintetica di un singolo valore JSON composto da un array di oggetti JSON con caratteristiche simili al precedente esempio:

        json
--------------------
 [{"n":1,"q":1},   +
  {"n":2,"q":4},   +
  {"n":3,"q":9},   +
  {"n":4,"q":16},  +
  {"n":5,"q":25},  +
  {"n":6,"q":36},  +
  {"n":7,"q":49},  +
  {"n":8,"q":64},  +
  {"n":9,"q":81},  +
  {"n":10,"q":100}]
(1 row)

Inutile sottolineare l’impatto di queste nuove funzionalità nello sviluppo, in particolare, di applicazioni web e mobile che memorizzano e recuperano dati JSON direttamente da PostgreSQL e le veicolano, ad esempio, con JQuery. Al prossimo articolo sulle novità di PostgreSQL 9.3!