L’aggiornamento risolve due problemi di sicurezza che causavano rispettivamente un crash del sistema e una escalation delle autorizzazioni. Inoltre corregge altri bug emersi negli ultimi tre mesi. Si incoraggiano gli utenti a pianificare l’aggiornamento dei server alla prima occasione possibile.

Aggiornamenti di sicurezza

Questo aggiornamento risolve due falle di sicurezza:

• CVE-2016-5423: certain nested CASE expressions can cause the server to crash.
• CVE-2016-5424: database and role names with embedded special characters can cause triggering code during administrative operations like pg_dumpall.

Il fix del secondo problema aggiunge anche una opzione, --reuse-previous, al comando \connect di psql. Dopo l’aggiornamento, pg_dumpall si rifiuterà di gestire nomi di ruolo e database contenenti un ritorno a capo. Per maggiori informazioni sui bug e sul loro impatto in termini di retro-compabilità, si faccia riferimento alle note di rilascio.

Altre correzioni e miglioramenti

Questo aggiornamento corregge anche un numero di bug emersi e riportati nei mesi precedenti. Alcuni di questi riguardano esclusivamente la 9.5, ma altri si riferiscono a tutte le versioni supportate. La lista di correzioni, in inglese, è la seguente:

• Fix misbehaviors of IS NULL/IS NOT NULL with composite values
• Fix three areas where INSERT … ON CONFLICT failed to work properly with other SQL features.
• Make INET and CIDR data types properly reject bad IPv6 values
• Prevent crash in close_ps() for NaN input coordinates
• Avoid possible crash in pg_get_expr()
• Fix several one-byte buffer over-reads in to_number()
• Don’t pre-plan query if WITH NO DATA is specified
• Avoid crash-unsafe state with expensive heap_update() paths
• Fix hint bit update during WAL replay of row locking operations
• Avoid unnecessary “could not serialize access” with FOR KEY SHARE
• Avoid crash in postgres -C when the specified variable is a null string
• Fix two issues with logical decoding and subtransactions
• Ensure that backends see up-to-date statistics for shared catalogs
• Avoid consuming a transaction ID during VACUUM
• Prevent possible failure when vacuuming multixact IDs in an upgraded database
• When a manual ANALYZE specifies colums, don’t reset changes_since_analyze
• Fix ANALYZE’s overestimation of n_distinct for nulls
• Fix bug in b-tree mark/restore processing
• Fix building of large (bigger than shared_buffers) hash indexes
• Prevent infinite loop in GiST index build with NaN values
• Fix possible crash during a nearest-neighbor indexscan
• Fix “PANIC: failed to add BRIN tuple” error
• Prevent possible crash during background worker shutdown
• Many fixes for issues in parallel pg_dump and pg_restore
• Make pg_basebackup accept -Z 0 as no compression
• Make regression tests safe for Danish and Welsh locales

La libreria client libpq è stata aggiornata per supportare il nuovo formato di versioning di PostgreSQL che sarà composto soltanto da due parti e non più tre come ora (e.g.: 10.0 invece di 9.5.4). Questo aggiornamento contiene anche la release 2016f di tzdata, con aggiornamenti per Kemerovo, Novosibirsk, Azerbaijan, Bielorussia e Marocco.

Uscita dal supporto comunitario per la versione 9.1

La versione 9.1 uscirà dal supporto comunitario a settembre 2016 (EOL, End-of-Life). Di conseguenza, questo aggiornamento sarà probabilmente l’ultimo per questa versione. Gli utenti di PostgreSQL 9.1 dovrebbero iniziare a pianificare un aggiornamento a una versione più recente prima di tale data. Si vedano le policy di versioning per maggiori informazioni sulle date di fine supporto comunitario delle varie versioni di PostgreSQL.

Istruzioni di aggiornamento

Come ogni aggiornamento di minor release, non è necessario eseguire alcun dump e restore dei database e neppure utilizzare pg_upgrade per effettuare questi ultimi aggiornamenti; è sufficiente spegnere il servizio PostgreSQL ed aggiornare i binari. Gli utenti che hanno saltato aggiornamenti precedenti, potrebbero necessitare di ulteriori operazioni da eseguire dopo l’aggiornamento; si vedano le varie note di rilascio per maggiori dettagli.

Link utili

• Download
• Release Notes
• Security Page
• Versioning Policy

L’estensione pgespresso, concepita dal nostro Simon Riggs, consentiva di marcare l’inizio e la fine del processo di backup anche su uno standby in sola lettura. Tramite pgespresso, gli utenti di Barman possono eseguire backup fisici via rsync/Ssh da un server in standby, scaricando la reale copia dal server master.

Questa funzionalità è chiamata backup concorrente ed è già disponibile in PostgreSQL attraverso il protocollo di streaming replication, via pg_basebackup.

La nuova API di PostgreSQL 9.6

L’ultima versione che pgespresso supporterà in termini di backup concorrente è PostgreSQL 9.6. Per quale motivo?

La API che PostgreSQL mette a disposizione per eseguire backup fisici di basso livello è stata estesa in modo da supportare nativamente il backup concorrente (o meglio, dovrei usare il termine “non esclusivo”). Non sono sicuro se Magnus (l’autore di questa patch) sia stato ispirato da pgespresso oppure no, ma ciò che conta è che il suo contributo sia più generico e robusto (dopo tutto, pgespresso è stato progettato per interagire soltanto con Barman).

Pertanto, PostgreSQL 9.6 e versioni future avranno al loro interno funzioni che permetteranno a Barman di richiedere un backup concorrente, rendendo pgespresso non più necessario.

Per maggiori dettagli su questa nuova API, ti consiglio di leggere la sezione che ho scritto nella pagina in inglese del Wiki di PostgreSQL “What’s new in PostgreSQL 9.6”. Per adesso, è importante sapere che:

• pg_start_backup() è stata modificata e un nuovo parametro adesso permette di specificare se il backup è esclusivo (default, per retro-compatibilità) oppure no;
• una nuova versione di pg_stop_backup() è stata fornita per i backup concorrenti: da un punto di vista tecnico, questa funzione adesso ritorna il contenuto della backup label e la mappa dei tablespace disponibili.

Barman e il backup concorrente di PostgreSQL 9.6

La cosa rilevante per i nostri cari utenti di Barman è che quest’ultimo gestirà in modo trasparente la nuova API, senza alcun impatto a livello di esperienza utente.

Di default, Barman richiederà un backup esclusivo (utilizzando le funzioni classiche disponibili sin da PostgreSQL 8). Ad ogni modo, puoi scatenare il nuovo comportamento impostando concurrent_backup nell’opzione globale/per server chiamata backup_options, come segue:

backup_options = concurrent_backup

In futuro, PostgreSQL dismetterà le funzioni per il backup esclusivo in favore di quelle per il concorrente, principalmente a causa di alcuni casi limite potenzialmente pericolosi. In particolare, la morte improvvisa di un server PostgreSQL prima di invocare pg_start_backup(), evento che lascia un file backup_label nella directory PGDATA e che impedisce al server di ripartire (e comunque, il comando barman check opportunamente configurato nel tuo sistema di monitoraggio e alerting è in grado di identificare questo problema).

Quando la nuova API per i backup diventerà quella principale per PostgreSQL, Barman agirà di conseguenza. Nel frattempo, ti invito a testare questa nuova funzionalità, attualmente disponibile solo su Github e che farà parte di Barman 1.6.2/1.7.0. Grazie!

Annie Prévot, CIO del CNAF, la Cassa Nazionale per gli Assegni Familiari della Francia, afferma:

“Il CNAF fornisce servizi a 11 milioni di persone ed eroga 73 miliardi di Euro ogni anno, attraverso 26 tipi di prestazioni. Questo servizio, essenziale per la popolazione, si basa su un sistema informativo che deve essere efficiente e affidabile. Con soddisfazione, il sistema di CNAF si basa su PostgreSQL per la gestione dei dati.”

UPSERT

Da molti anni una delle funzionalità più richieste dagli sviluppatori di applicazioni, “UPSERT” è la forma breve di “INSERT, ON CONFLICT UPDATE” e permette di trattare in modo identico record nuovi e aggiornati. UPSERT semplifica lo sviluppo di applicazioni web e mobile incaricando il database di gestire conflitti fra modifiche concorrenti ai dati. Inoltre questa funzionalità abbatte l’ultima barriera significativa per la migrazione di applicazioni legacy MySQL verso PostgreSQL.

Sviluppata nel corso degli ultimi due anni da Peter Geoghegan di Heroku, l’implementazione di PostgreSQL di UPSERT è notevolmente più flessibile e potente di quelle offerte da altri database relazionali. La nuova clausola ON CONFLICT consente di ignorare nuovi dati, oppure di aggiornare diverse colonne o relazioni in modo da supportare complesse catene ETL (Extract, Transform, Load) per il caricamento massivo di dati. Inoltre, come tutto PostgreSQL, è progettata per utilizzo concorrente e per integrarsi con tutte le altre funzionalità, replica logica compresa.

Sicurezza a livello di riga

PostgreSQL continua a espandere le sue capacità nel campo della protezione dei dati, aggiungendo il supporto per la sicurezza a livello di riga – in inglese Row Level Security (RLS). RLS implementa un verso controllo di accesso al dato per riga e per colonna e si integra con stack esterni di sicurezza come SE Linux. PostgreSQL è già noto per essere “il più sicuro di default”. RLS consolida questa posizione, rendendolo la migliore scelta per applicazioni con elevati requisiti di sicurezza dei dati; in particolare, conformità a PCI, direttiva europea su Data Protection e standard di protezione dei dati in ambito sanitario.

RLS è l’apice di cinque anni di funzionalità sulla sicurezza aggiunte a PostgreSQL e comprende l’ampio lavoro svolto da KaiGai Kohei di NEC, Stephen Frost di Crunchy Data e Dean Rasheed. Grazie a RLS, gli amministratori di database possono impostare politiche di sicurezza per gestire quali righe particolari utenti sono autorizzati ad aggiornare o a vedere. Implementare la sicurezza del dato in questo modo rende il database resistente a exploit di tipo SQL injection, nonché ad altre falle di sicurezza a livello applicativo.

Funzionalità per i Big Data

PostgreSQL 9.5 include molteplici funzionalità per database di grandi dimensioni e per la loro integrazione con altri sistemi Big Data. Tali funzionalità riaffermano il ruolo dominante di PostgreSQL nel mercato open source dei Big Data, in forte crescita. Fra queste, vale la pena citare:

Indici BRIN

questo nuovo tipo di indice supporta la creazione di indici piccoli ma al tempo stesso molto efficienti per tabelle molto grandi, “naturalmente ordinate”. Per esempio, tabelle contenenti dati di log con miliardi di record possono essere indicizzate e ricercate nel 5% del tempo richiesto da un indice BTree tradizionale.

Ordinamenti più veloci

PostgreSQL riesce a ordinare più velocemente dati testuali e di tipo NUMERIC, utilizzando un algoritmo chiamato “chiavi abbreviate”. Questo algoritmo è in grado di accelerare query che necessitano di ordinare grandi moli di dati da 2 a 12 volte, e di velocizzare la creazione di indici fino a 20 volte.

CUBE, ROLLUP e GROUPING SET

queste nuove clausole dello standard SQL permettono di produrre report a più livelli di riepilogo utilizzando una sola query invece di molteplici, come in passato. CUBE inoltre consente di integrare PostgreSQL con strumenti di reporting come Tableau, tipici di ambienti Online Analytic Processing (OLAP).

Foreign Data Wrapper (FDW)

i FDW consentono già a PostgreSQL di essere utilizzato come motore di query per altri sistemi Big Data come Hadoop e Cassandra. La versione 9.5 aggiunge IMPORT FOREIGN SCHEMA e la propagazione (“pushdown“) delle JOIN, rendendo le connessioni per query a database esterni sia più facili da configurare che più efficienti.

TABLESAMPLE

questa clausola SQL consente di ottenere in modo veloce un campione statistico di una tabella enorme, senza la necessità di ordinamenti dispendiosi.

“Il nuovo indice BRIN di PostgreSQL 9.5 è una funzionalità molto potente che permette a Postgres di gestire e indicizzare volumi di dati che fino ad ora erano impraticabili, se non addirittura impossibili. È in grado di portare la scalabilità e le prestazioni oltre i limiti dei tradizionali database relazionali e rende PostgreSQL una soluzione perfetta per analytics con Big Data”, afferma Boyan Botev, Lead Database Administrator, Premier, Inc.

Vuoi saperne di più?

Per ulteriori informazioni e spiegazioni sulle funzionalità aggiunte in PostgreSQL 9.5, consulta il press kit ufficiale rilasciato dalla Comunità.

Segui inoltre la nostra serie di articoli in italiano su PostgreSQL 9.5.

Grazie al linguaggio SQL è possibile, in ogni istante, controllare lo stato di funzionamento del processo di archiviazione dei log transazionali (WAL), componente cruciale di un sistema di disaster recovery con PostgreSQL.

Introduzione e motivazioni

Questa vista nasce dall’esigenza, emersa in questi anni, di utilizzare Barman come soluzione di disaster recovery di database PostgreSQL in ambienti in continuità operativa.

In particolare, alcune delle necessità e delle domande ricorrenti che DBA, sistemisti, CTO e CIO legittimamente ci chiedono, sono:

• Di quanto spazio disco avrò bisogno?
• Come posso tenere sotto controllo il processo di backup e di archiviazione continua?

Il punto di partenza, come è naturale che sia, è un requisito di business, che si traduce nel concetto di retention policy. Solitamente, un’azienda definisce un piano di disaster recovery all’interno di un piano di continuità operativa, dove è stabilito chiaramente il periodo di conservazione dei dati di backup. Negli stessi documenti troviamo sia il recovery point objective (RPO) che il recovery time objective (RTO), le due metriche fondamentali che misurano la quantità di dati che un’azienda può tollerare di perdere e il tempo massimo di ripristino in seguito a un disastro.
Il monitoraggio e lo studio del comportamento passato di un database sono elementi fondamentali per dimensionare, a livello di storage, una soluzione di backup.

Ad esempio, un’azienda può decidere di conservare i dati di un database PostgreSQL per un mese, in modo da ricostruire la situazione del database in maniera consistente in qualsiasi istante a partire dal primo backup a disposizione, fino all’ultimo file WAL correttamente archiviato (tramite il robustissimo meccanismo di Point-In-Time-Recovery di PostgreSQL).

La dimensione necessaria è data non solo dal numero di backup completi periodici (ad esempio uno a settimana), ma anche dal numero di file WAL archiviati, ognuno contenente le transazioni correttamente eseguite sul database in modo differenziale.

Una delle metriche necessarie è pertanto il numero di file WAL archiviati al secondo, tramite le quali è possibile stimare il numero di WAL prodotti in una settimana ed essere in grado di fare previsioni di utilizzo del disco.

A meno di non usare strumenti di campionamento e di trending (e.g. Munin), di esaminare i timestamp dei file WAL sfruttando un wal_keep_segments alto, oppure delegare questa informazione allo script personalizzato di archiviazione invocato da archive_command, fino alla versione 9.4, PostgreSQL non era in grado di fornire statistiche sul numero di file WAL archiviati, l’orario di archiviazione, l’ultimo WAL archiviato e così via. Tantomeno poteva riportare informazioni in merito al numero di file WAL per i quali l’archiviazione era fallita e l’orario di ultimo fallimento.

Sono questi i motivi per cui un anno fa ho deciso di scrivere una piccola patch per Postgres, patch che è stata poi inserita nel core all’interno della versione 9.4.

Questa patch aggiunge una statistica real-time al catalogo di PostgreSQL chiamata pg_stat_archiver.

Overview della statistica

La vista pg_stat_archiver di PostgreSQL 9.4 rende disponibile a tutti coloro che utilizzano Barman o il backup continuo classico tramite WAL file shipping, i seguenti campi:

• archived_count: numero di file WAL archiviati con successo
• last_archived_wal: nome dell’ultimo file WAL archiviato con successo
• last_archived_time: orario dell’ultima archiviazione di WAL eseguita con successo
• failed_count: numero di tentativi falliti di archiviazione di WAL
• last_failed_wal: nome dell’ultimo file WAL con tentativo di archiviazione fallito
• last_failed_time: orario dell’ultima archiviazione di WAL fallita
• stats_reset: orario di reset delle statistiche

Ecco un esempio ricavato da un database server locale, poco utilizzato:

postgres=# SELECT * FROM pg_stat_archiver;
-[ RECORD 1 ]------+-----------------------------------------
archived_count     | 17
last_archived_wal  | 00000001000000000000000B.00000028.backup
last_archived_time | 2014-12-23 08:40:17.858291+01
failed_count       | 13
last_failed_wal    | 000000010000000000000001
last_failed_time   | 2014-12-04 13:09:07.348307+01
stats_reset        | 2014-12-03 16:52:21.755025+01

Essenzialmente, una volta attivata l’archiviazione continua con archive_mode, PostgreSQL si fa responsabile che, per ogni file WAL prodotto, il comando archive_command venga eseguito con successo, riprovando all’infinito (spazio su disco permettendo) in caso di fallimento.

A differenza delle versioni precedenti, PostgreSQL 9.4 è in grado adesso di raccogliere alcune informazioni sui due principali eventi che possono verificarsi con l’archiviazione: successo e fallimento. In particolare, per entrambe le operazioni vengono resi disponibili:

• Conteggio (a partire dall’inizializzazione del cluster oppure dall’ultimo reset delle statistiche);
• WAL di riferimento dell’ultima operazione;
• Orario dell’ultima operazione.

Tra l’altro, è possibile azzerare le statistiche di archiviazione con l’istruzione:

-- Richiede privilegi superuser
SELECT pg_stat_reset_shared('archiver');

Integrazione con Barman

A partire dalla versione 1.4, Barman sfrutterà la vista pg_stat_archiver per i database PostgreSQL 9.4 in modo automatico e trasparente, riportando le informazioni di archiviazione nei classici comandi Barman di visualizzazione di un server, come status e show-server.

Inoltre, sfruttando la potenza del linguaggio SQL, è stata migliorata l’affidabilità del comando check, adesso in grado di rilevare un problema di archiviazione direttamente dalla fonte.

Esaminiamo velocemente la query introdotta in Barman:

SELECT *,
    current_setting('archive_mode')::BOOLEAN
        AND (last_failed_wal IS NULL
            OR last_failed_wal <= last_archived_wal)
        AS is_archiving,
    CAST (archived_count AS NUMERIC)
        / EXTRACT (EPOCH FROM age(now(), stats_reset))
        AS current_archived_wals_per_second
FROM pg_stat_archiver

Oltre a recuperare tutte le colonne della vista pg_stat_archiver, la query calcola al volo due campi, direttamente dalla fonte:

• is_archiving: il processo di archiviazione dei WAL è in corso oppure no?
• current_archived_wals_per_second: frequenza di WAL archiviati per secondo

Il campo is_archiving deve essere sempre TRUE, in quanto il processo di archiviazione è necessario per Barman. Pertanto, archive_mode deve essere attivo e il valore dell’ultimo WAL deve essere non definito (NULL) oppure non successivo all’ultimo WAL correttamente archiviato. Questo controllo è adesso parte integrante del comando barman check su server Postgres 9.4 (e future versioni).

Il secondo campo invece restituisce una statistica molto interessante sul workload prodotto dai server Postgres e permette pertanto di stimare lo spazio su disco richiesto per memorizzare (anche in modo compresso) giorni, settimane e mesi di file WAL (rispondendo così a una delle importanti domande iniziali).

Come controllare lo stato di funzionamento dell’archiviazione

Grazie a pg_stat_archiver, controllare lo stato di funzionamento dell’archiviazione continua dei WAL si riduce all’esecuzione di una query SQL.

È possibile impiegare la query esposta in precedenza, già utilizzata in Barman, per verificare che l’archiviazione stia procedendo con successo, integrandola nelle sonde o plugin del sistema di alerting utilizzato in azienda.

Coloro che utilizzano Barman con server PostgreSQL 9.4 e hanno già integrato barman check all’interno Nagios o Icinga, beneficeranno in modo trasparente di questa funzionalità.

Conclusioni

La vista pg_stat_archiver, nella sua semplicità, rappresenta uno strumento molto importante per coloro che considerano la disaster recovery una componente cruciale, e non periferica, di un sistema PostgreSQL in business continuity.

Anche se PostgreSQL permette di eseguire backup utilizzando la replica in streaming, l’archiviazione continua dei file WAL tramite shipping rappresenta comunque un metodo di fallback sicuro e affidabile (e comunque l’unico finora supportato da Barman). Pertanto, il corretto monitoraggio di questa componente aumenta sensibilmente la robustezza di tutta la soluzione di database Postgres.

Infine, poter disporre di statistiche circa il numero di WAL archiviati (e pertanto prodotti) da un server PostgreSQL in un periodo di riferimento, permette di conoscere con una semplice query il workload transazionale e poter fare previsioni sull’occupazione a livello di disco di una soluzione di backup.

Il talk racconta l’esperienza concreta di 2ndQuadrant Italia in termini di adozione della cultura devops (volutamente scritta con le lettere “D” e “O” minuscole a simbolizzare la completa condivisione fra sviluppatori e amministratori) nella gestione quotidiana di database PostgreSQL e di progetti di sviluppo, sia interni che commissionati da clienti provenienti da tutto il mondo.

L’intervento, oltre a coprire concetti introduttivi, si concentrerà su aspetti organizzativi, sui processi, sul ruolo del DBA, sull’open source e infine sugli strumenti legati all’impiego di database PostgreSQL in un contesto devops.

La presentazione, in lingua inglese, ha già riscosso successo sia al FOSDEM 2014 che al Codemotion 2014 di Roma.

Barman 1.3.3 è in grado di inviare alert nel caso in cui l’ultimo backup disponibile di un server sia più vecchio di un dato intervallo di tempo (ad esempio, una settimana). Inoltre, Barman può adesso riprovare automaticamente la copia dei backup in seguito a problemi temporanei come la perdita della connessione di rete. È stato poi implementato un algoritmo ottimizzato per la copia tramite rsync, al fine di migliorare le prestazioni durante le operazioni di recovery incrementale.

Le consuete attività di bug fixing e di rifattorizzazione del codice hanno fatto sì che la release 1.3.3 di Barman risulti essere la versione più stabile fra quelle disponibili e per questo vi consigliamo di effettuare l’aggiornamento delle vostre installazioni di Barman il prima possibile.

L’ultima nota di rilievo – ma non certo per importanza – è riservata agli utilizzatori che appartengono all’era giurassica di PostgreSQL 8.3 (senza offesa! ;) ): possono finalmente effettuare il backup dei loro database con Barman.

Un ringraziamento speciale per il contributo allo sviluppo di questa release va a Agile Business Group (www.agilebg.com), Jobrapido (www.jobrapido.com), Navionics (www.navionics.com) e Subito.it (www.subito.it).

Per una lista completa delle modifiche, si faccia riferimento alle note di rilascio nel comunicato ufficiale in lingua inglese. Maggiori informazioni su Barman sono disponibili sul relativo sito all’indirizzo www.pgbarman.org.

A proposito di Barman

Barman (Backup and Recovery Manager per PostgreSQL) è un software open-source scritto in Python, progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3. Consente di eseguire backup remoti su più server in ambienti business critical. Strumento di sicuro supporto ai DBA durante la fase di recupero dei dati. Tra le caratteristiche più apprezzate di Barman emergono: catalogo di backup, politiche di conservazione (retention policy), backup e recovery da remoto, archiviazione e compressione dei file WAL e dei backup.

Pincipali Feature

Le nuove feature più importanti disponibili per il test nella versione Beta, includono:

• Il nuovo tipo JSONB, comprendente indici e operatori per dati di documento.
• La nuova API di Data Change Streaming permette la decodifica e la trasformazione dello stream di replica.
• Le viste materializzate con la funzione “Refresh Concurrently”.
• ALTER SYSTEM SET, che consente modifiche a postgresql.conf dalla riga di comando SQL.

Queste feature ampliano le capacità di PostgreSQL, introducono nuove sintassi, API e interfacce di gestione.

Altre funzionalità

Ci sono molte altre funzionalità nella versione Beta della 9.4 e tutte hanno bisogno di essere testate da voi:

• Dynamic Background Worker
• Replication Slot
• Miglioramenti nella scalabilità in scrittura
• Miglioramenti di performance per funzioni aggregate
• Riduzione del volume dei WAL
• Indici GIN del 50% più piccoli e veloci
• Viste “security barrier” aggiornabili
• Nuove funzioni per manipolare array e tabelle
• Standby ritardati
• Aggiornamenti MVCC del catalogo di sistema
• Diminuzione del livello di lock per alcuni comandi ALTER TABLE
• Controllo della velocità per il backup
• WITHIN GROUP

Ci sono anche molti cambiamenti interni al funzionamento di Write Ahead Log (WAL), indici GIN, replica, aggregazione, e gestione del catalogo del sistema. In pratica, abbiamo bisogno del vostro aiuto per trovare qualsiasi nuovo bug che potremmo aver introdotto in queste aree prima di rilasciare la release 9.4.

Per un elenco completo delle feature della versione Beta 9.4, potete far riferimento alle note di rilascio. Descrizioni aggiuntive e informazioni sulle nuove feature sono disponibili sul Wiki, alla pagina 9.4 Features Wiki Page.

Testa la versione Beta 1 di 9.4 Beta adesso

Abbiamo bisogno della nostra Community per avere supporto nei test della nuova versione, al fine di garantire elevate prestazioni e l’assenza di bug. Vi preghiamo di effettuare il download di PostgreSQL 9.4 Beta 1 e di provarla con i vostri carichi di lavoro e le vostre applicazioni il prima possibile. Date i vostri feedback agli sviluppatori di PostgreSQL. Le feature e le API nella versione Beta 1 non cambieranno in modo sostanziale prima del rilascio della release finale, in modo da permettervi di cominciare a sviluppare applicazioni basandovi su Postgres 9.4. Maggiori informazioni su come eseguire test e riportare problemi.

Scarica PostgreSQL 9.4 Beta 1, compresi file binari e installer per Windows, Linux e Mac dalla nostra pagina di download.

La documentazione completa della nuova release è disponibile online – e si installa anche con PostgreSQL.

Barman adesso è in grado di supportare il backup concorrente di server PostgreSQL 9.2 e 9.3 servers, utilizzando l’estensione pgespresso e permettendo agli utenti di eseguire backup da un server in standby.

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

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

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

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.