Feeds

FeedRSSLast fetchedNext fetched after
/var/tmp/it XML 15:01, sabato, 01 ottobre 16:01, sabato, 01 ottobre
2ndQuadrant XML 15:01, sabato, 01 ottobre 16:01, sabato, 01 ottobre
:: Luca Ferrari :: XML 15:01, sabato, 01 ottobre 16:01, sabato, 01 ottobre
Denis Gasparin » Planet PostgreSQL XML 15:01, sabato, 01 ottobre 16:01, sabato, 01 ottobre
Il blog di Enrico Pirozzi - Postgresql XML 15:01, sabato, 01 ottobre 16:01, sabato, 01 ottobre
PostgreSQL – Blog di Diego Cinelli XML 15:01, sabato, 01 ottobre 16:01, sabato, 01 ottobre

mercoledì, 28 settembre

12:19

Ritorno al futuro con PostgreSQL, parte 2: Come usare pg_rewind [2ndQuadrant]

backtothefuture_02

Nell’articolo precedente abbiamo visto come funziona pg_rewind per riallineare le timeline di un cluster di replica semplice composta da un master che replica su di un singolo standby. In un tale contesto, in un eventuale switchover, solo due nodi sono chiamati in causa. Ma cosa succede quando iniziano ad esserci diversi nodi di standby, anche in cascata?

Consideriamo adesso un cluster di replica un pò più complesso, ma sempre basato su PostgreSQL 9.5, nel quale ci sono due standby non in cascata; in modo simile a quanto già fatto nel mio primo articolo dedicato a pg_rewind, creiamo questo cluster. Iniziamo col master:

# Set PATH variable
export PATH=/usr/pgsql-9.5/bin:${PATH}

# This is the directory where we will be working on
# Feel free to change it and the rest of the script
# will adapt itself
WORKDIR=/var/lib/pgsql/9.5

# Environment variables for PGDATA and archive directories
MASTER_PGDATA=${WORKDIR}/master
STANDBY1_PGDATA=${WORKDIR}/standby1
STANDBY2_PGDATA=${WORKDIR}/standby2
ARCHIVE_DIR=${WORKDIR}/archive

# Initialise the cluster
initdb --data-checksums -D ${MASTER_PGDATA}

# Basic configuration of PostgreSQL
cat >> ${MASTER_PGDATA}/postgresql.conf <<EOF
archive_command = 'cp %p ${ARCHIVE_DIR}/%f'
archive_mode = on
wal_level = hot_standby
max_wal_senders = 10
min_wal_size = '32MB'
max_wal_size = '32MB'
hot_standby = on
wal_log_hints = on
EOF

cat >> ${MASTER_PGDATA}/pg_hba.conf <<EOF
# Trust local access for replication
# BE CAREFUL WHEN DOING THIS IN PRODUCTION
local replication replication trust
EOF

# Create the archive directory
mkdir -p ${ARCHIVE_DIR}

# Start the master
pg_ctl -D ${MASTER_PGDATA} -l ${WORKDIR}/master.log start

# Create the replication user
psql -c "CREATE USER replication WITH replication"

E procediamo poi con il primo standby:

# Create the first standby
pg_basebackup -D ${STANDBY1_PGDATA} -R -c fast -U replication -x

cat >> ${STANDBY1_PGDATA}/postgresql.conf <<EOF
port = 5433
EOF

# Start the first standby
pg_ctl -D ${STANDBY1_PGDATA} -l ${WORKDIR}/standby1.log start

In modo identico, creiamo il secondo standby:

# Create the second standby
pg_basebackup -D ${STANDBY2_PGDATA} -R -c fast -U replication -x

cat >> ${STANDBY2_PGDATA}/postgresql.conf <<EOF
port = 5434
EOF

# Start the second standby
pg_ctl -D ${STANDBY2_PGDATA} -l ${WORKDIR}/standby2.log start

Consideriamo anche in questo caso che siano mantenuti pochi WAL sul master (notare come è stato valorizzato il parametro max_wal_size) che vengono opportunamente archiviati.

Se inseriamo un pò di dati sul master, li vedremo visibili anche su entrambi gli (hot) standby.

Promuoviamo adesso uno dei due standby a nuovo master (ad esempio, quello basato su ${STANDBY1_PGDATA}), lasciando gli altri nodi inalterati:

pg_ctl -D ${STANDBY1_PGDATA} promote

Le modifiche eventualmente apportate al master non saranno visibili sullo standby promosso, mentra saranno visibili sull’altro; nella directory archive/ è possibile trovare il file 00000002.history, che mostra un cambio nella timeline avvenuto durante la promozione, come visto anche nel precedente caso.

Tentiamo adesso di correggere l’errore, ricreando il cluster di replica come in origine, con lo standby promosso come nuovo master e gli altri due nodi come rispettivi standby: la procedurà che cercherò di seguire sarà

  1. spengere il vecchio master e risincronizzarlo a partire dallo standby promosso usando pg_rewind
  2. spengere il secondo standby e risincronizzarlo a partire dallo standby promosso, come fatto nel punto precedente

Iniziamo col primo punto:

~$ pg_ctl -D ${MASTER_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/501E680 on timeline 1
could not open file "/var/lib/pgsql/9.5/master/pg_xlog/000000010000000000000005": No such file or directory

could not find previous WAL record at 0/501E680
Failure, exiting

Come ci aspettavamo, mancano i WAL! Sì, so di essere ripetitivo, ma come già detto è sempre buona norma archiviare i WAL! Infatti, adesso è possibile recuperare i WAL mancanti: qui la procedurà sarà quella di copiarli manualmente per poi inserirli all’interno della pg_xlog/ del master, per poi rilanciare nuovamente pg_rewind (ma considerate anche l’uso di Barman per questo):

~$ cp ${ARCHIVE_DIR}/00000001000000000000000[56] ${MASTER_PGDATA}/pg_xlog/
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/501E680 on timeline 1
rewinding from last common checkpoint at 0/501E5D8 on timeline 1
Done!

Ricordiamoci di cambiare opportunamente il parametro primary_conninfo all’interno del file recovery.conf ed il parametro port nel postgresql.conf, ed il vecchio master è ora pronto per seguire lo standby promosso. Facciamo adesso lo stesso anche col secondo standby:

~$ pg_ctl -D ${STANDBY2_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${STANDBY2_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
could not find common ancestor of the source and target cluster's timelines
Failure, exiting

Dunque, in questo caso non funziona: il secondo standby deve essere comunque risincronizzato dallo standby promosso tramite un nuovo base backup…

Conclusioni

pg_rewind è molto utile per risincronizzare i nodi tra di loro in un cluster di replica. Tuttavia, per infrastrutture che prevedono più standby non è possibile risincronizzare ogni nodo con solo questo tool.

Nonostante questo l’eventuale downtime degli standby è ridotto: un nodo può essere comunque velocemente riallineato, nell’attesa che gli altri vengano poi man mano aggiunti con nuovi base backup.

PostgreSQL 9.6 introduce una nuova, interessante funzionalità per pg_rewind: il suo orizzonte di visibilità può essere esteso e sarà sempre possibile trovare un punto comune nella timeline di un cluster di replica… non perdere la terza e ultima parte, dedicata alle novità di pg_rewind presenti in PostgreSQL 9.6!

domenica, 18 settembre

18:42

PGDay.IT 2016: Call For Papers [:: Luca Ferrari ::]

Ve ne sarete ovviamente già accorti, perché è da circa una settimana, che la Call For Papers per il PGDay.IT 2016 è aperta.
C'è tempo fino a MARTEDi' 11 OTTOBRE (ore 23:59).
Cosa bisgona fare? Vincere la timidezza e inviare il proprio contributo per talk/tutorial seguendo le istruzioni riportate qui. Ogni singolo contributo è importante e verrà valutato attentamente al fine di garantire un grandioso programma della decima edizione della conferenza.

18:42

PGDay.IT 2016: it's time for you to speak! [:: Luca Ferrari ::]

As you probably already know the Call For Papers for the PGDay.IT 2016 is now open. Please see the details here and send your contribution following the instructions. The organizing committee will review each proposal in order to deliver a great program for the tenth edition of the italian PostgreSQL based conference.

lunedì, 12 settembre

11:00

Ritorno al Futuro con PostgreSQL, parte 1: Introduzione a pg_rewind [2ndQuadrant]

backtothefuture_01

PostgreSQL 9.5 introduce pg_rewind, un tool per risincronizzare un vecchio master con uno standby promosso che funziona anche se nel frattempo, non volutamente, quest’ultimo ha proseguito nella sua timeline. Questo è il caso, ad esempio, di uno switchover non eseguito con successo.

Avete mai concluso uno switchover con uno “split brain”? Questa situazione succede quando invece che aver invertito i ruoli tra master e standby, ottenete due master ciascuno con la sua propria timeline. È in situazioni come queste che pg_rewind viene in aiuto dei DBA PostgreSQL che si devono confrontare i problemi di alta disponibilità (HA).

Fino alla versione 9.5 di PostgreSQL c’era una sola soluzione possibile: risincronizzare la PGDATA del vecchio master con un nuovo base backup a partire dallo standby promosso e poi aggiungerlo come nuovo standby al cluster di replica. Questo diventa un problema quando le dimensioni del database sono notevoli: nel caso di diverse centinaia di GB non è semplice effettuare queste operazioni mantenendo allo stesso tempo downtime ridotti.

Riportare un database allo stato in cui si trovava in un determinato momento del passato può essere complicato, ma nonostante questo ci sono varie strategia. Suggerisco a chi è interessato di dare un’occhiata agli articoli di Gulcin che affrontano il tema in PostgreSQL e che menziona anche l’uso di pg_rewind.

Come funziona pg_rewind

pg_rewind è in grado di leggere tutti i file contenuti nella PGDATA del vecchio master, identificare i blocchi modificati durante un eventuale cambio di timeline e quindi copiare solo questi dallo standby promosso, in modo da riallinearsi. Come “effetto collaterale”, anche i file di configurazione vengono copiati e sovrascritti, quindi è compito del DBA quello di riadattarli eventualmente al nodo in esame. Ad ogni modo, questo evita di dover risincronizzare totalmente la PGDATA.

Per fare questo, è necessario avere tutti i WAL prodotti negli ultimi istanti di vita del vecchio master precedenti lo switchover. Le modifiche sono individuate dal confronto tra i blocchi di dati presenti nella PGDATA con le modifiche inserite nei WAL. Una volta identificati i blocchi modificati, vengono sostituiti con quelli presenti nello standby promosso, mimando una sorta di “rewind” della timeline.

Inoltre:

  • le istanze debbono essere state inizializzate con l’opzione “-k” (o --data-checksums)
  • il parametro wal_log_hints deve essere abilitato

Fino a PostgreSQL 9.5, i WAL necessari sono quelli a partire dall’ultimo checkpoint, dato che pg_rewind non è in grado di andare indietro nella timeline ulteriormente.

Per capire meglio come funziona, consideriamo questo semplice esempio:

# Set PATH variable
export PATH=/usr/pgsql-9.5/bin:${PATH}

# This is the directory where we will be working on
# Feel free to change it and the rest of the script
# will adapt itself
WORKDIR=/var/lib/pgsql/9.5

# Environment variables for PGDATA and archive directories
MASTER_PGDATA=${WORKDIR}/master
STANDBY1_PGDATA=${WORKDIR}/standby1
ARCHIVE_DIR=${WORKDIR}/archive

# Initialise the cluster
initdb --data-checksums -D ${MASTER_PGDATA}

# Basic configuration of PostgreSQL
cat >> ${MASTER_PGDATA}/postgresql.conf <<EOF
archive_command = 'cp %p ${ARCHIVE_DIR}/%f'
archive_mode = on
wal_level = hot_standby
max_wal_senders = 10
min_wal_size = '32MB'
max_wal_size = '32MB'
hot_standby = on
wal_log_hints = on
EOF

cat >> ${MASTER_PGDATA}/pg_hba.conf <<EOF
# Trust local access for replication
# BE CAREFUL WHEN DOING THIS IN PRODUCTION
local replication replication trust
EOF

# Create the archive directory
mkdir -p ${ARCHIVE_DIR}

# Start the master
pg_ctl -D ${MASTER_PGDATA} -l ${WORKDIR}/master.log start

# Create the replication user
psql -c "CREATE USER replication WITH replication"

(notare il basso numero di WAL mantenuti volutamente nel master), ed uno standby:

# Create the first standby
pg_basebackup -D ${STANDBY1_PGDATA} -R -c fast -U replication -x

cat >> ${STANDBY1_PGDATA}/postgresql.conf <<EOF
port = 5433
EOF

# Start the first standby
pg_ctl -D ${STANDBY1_PGDATA} -l ${WORKDIR}/standby1.log start

Inseriamo alcuni dati sul master: questi saranno visibili anche dallo (hot) standby.

Promuoviamo adesso lo standby, lasciando inalterato il master:

pg_ctl -D ${STANDBY1_PGDATA} promote

Se adesso aggiorniamo il master i cambiamenti non saranno più visibili dallo standby. Inoltre, nella directory archive/ è presente il file 00000002.history e questo mostra che c’è stato un cambio di timeline durantela promozione.

Proviamo adesso ad effettuare il “rewind” del master, e ad aggiungerlo in replica allo standby promosso:

~$ pg_ctl -D ${MASTER_PGDATA} stop
waiting for server to shut down.... done
server stopped
~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"

Va notato che per la connessione al server sorgente – lo standby promosso – è stato usato l’utente postgres perché pg_rewind necessita di una connessione tramite superuser per ispezionare i blocchi di dati.

Se il parametro max_wal_size non è sufficientemente alto per mantenere nella pg_xlog/ del (vecchio) master i WAL necessari, come volutamente configurato nel nostro esempio, viene emesso un errore come il seguente:

The servers diverged at WAL position 0/3015938 on timeline 1.
could not open file "/var/lib/pgsql/9.5/master/pg_xlog/000000010000000000000002": No such file or directory

could not find previous WAL record at 0/3015938
Failure, exiting

Ci sono due possibili soluzioni a questo:

  • copiare manualmente i WAL mancanti dall’archivio alla directory pg_xlog/ del master, a partire da quello riportato nel messaggio di errore
  • configurare opportunamente il parametro restore_command all’interno del file recovery.conf da includere nella PGDATA del (vecchio) master, così che pg_rewind troverà automaticamente i WAL mancanti.

La seconda è probabilmente la più adatta. Pensiamo, ad esempio, al caso in cui l’archivio di WAL è gestito tramite Barman: il restore_command potrebbe essere basato sulla funzionalità get-wal di Barman, come chiaramente spiegato in questo interessante articolo di Gabriele. Così facendo, Barman può essere usato come una possibile sorgente da cui prelevare i WAL necessari a pg_rewind.

Una volta che tutti i WAL necessari sono disponibili, pg_rewind può essere nuovamente eseguito, questa volta correttamente, ottenendo il seguente messaggio:

~$ pg_rewind --target-pgdata=${MASTER_PGDATA} \
    --source-server="port=5433 user=postgres dbname=postgres"
servers diverged at WAL position 0/3015938 on timeline 1
rewinding from last common checkpoint at 0/3000140 on timeline 1
Done!

Va ribadito che adesso verranno copiati solo pochi blocchi di dati della PGDATA, quelli modificati durante lo split-brain, anche se il database occupasse centinaia di GB! Ricordiamoci poi che anche le configurazioni sono state copiate e sovrascritte, incluso un eventuale recovery.conf già presente nella PGDATA del vecchio master che deve essere convertito in nuovo standby. Quindi, **bisogna ricordarsi di*:

  • modificare la porta utilizzata dall’istanza (5432 nel nostro caso) nel postgresql.conf;
  • modificare la primary_conninfo nel recovery.conf in modo da assicurarsi che il vecchio master sia in grado di poter effettuare la connessione streaming verso lo standby promosso a nuovo master.

Una volta che questo è stato fatto, basta far partire nuovamente il vecchio master e questo sarà in grado di seguire in replica quello nuovo.

Avete cluster di replica più complessi di questo basato su due soli nodi? Non preoccupatevi! La seconda parte entrerà ancor più nel dettaglio nel funzionamento di pg_rewind in PostgreSQL 9.5!

venerdì, 09 settembre

18:36

E' ora di rimboccarsi le maniche: PGDay.IT X! [:: Luca Ferrari ::]

E' ufficiale: il PGDay.IT 2016 è in corso di organizzazione.
La dcima edizione della conferenza nazionale dedicata a PostgreSQL si svolgerà a Prato, nella splendida sede offerta dalla Camera di Commercio (sede già sfruttata l'anno precedente).
La data è il 13 Dicembre 2016.

pgday_468x60_it

Fra pochi giorni sarà disponibile la Call For Papers e gli organizzatori si metteranno al lavoro per selezionare gli interventi e offrire un programma degno di nota per questa edizione così importante nella storia di ITPUG e di PostgreSQL in Italia.

Per maggiori informazioni vedere il sito ufficiale 2016.pgday.it.

giovedì, 11 agosto

15:00

Rilascio aggiornamenti di sicurezza, 11 agosto 2016 [2ndQuadrant]

Il PGDG (PostgreSQL Global Development Group) ha rilasciato un aggiornamento per tutte le versioni del sistema di database PostgreSQL attualmente supportate, composto dalle “minor release” 9.5.4, 9.4.9, 9.3.14, 9.2.18 e 9.1.23.

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

lunedì, 11 luglio

09:25

PostgreSQL 9.6: sequential scan parallelo [2ndQuadrant]

Parallel-Sequential-Scan

Per lungo tempo una delle più note mancanze di PostgreSQL è stata la possibilità di parallelizzare le query. Con l’uscita della versione 9.6 non sarà più così. È stato infatti svolto un grande lavoro sul tema, per il quale il primo risultato è stato il commit 80558c1, in cui viene introdotta la parallelizzazione dei sequential scan in alcuni casi che vedremo nel corso di questo articolo.

Innanzitutto, una premessa: lo sviluppo di questa feature è stato continuo e alcuni parametri hanno cambiato nome nel susseguirsi di commit. L’articolo è stato scritto con un checkout al 17 giugno, e presenta alcune caratteristiche che saranno presenti solo dalla beta2 della 9.6.

Rispetto alla major 9.5 sono stati introdotti nuovi parametri all’interno della configurazione. Questi sono:

  • max_parallel_workers_per_gather: il numero di worker che possono assistere un sequential scan su una tabella;
  • min_parallel_relation_size: la dimensione minima che deve avere una relazione affinché il planner consideri l’uso di worker aggiuntivi;
  • parallel_setup_cost: parametro del planner che valuta il costo di istanziare un worker;
  • parallel_tuple_cost: parametro del planner che valuta il costo di trasferire una tupla da un worker a un altro;
  • force_parallel_mode: parametro utile per i test, forza il parallelismo anche su query su cui il planner agirebbe in altri modi.

Vediamo come i worker aggiuntivi possono essere usati per velocizzare le nostre query. Creiamo una tabella di test con un campo INT e cento milioni di record:

postgres=# CREATE TABLE test (i int);
CREATE TABLE
postgres=# INSERT INTO test SELECT generate_series(1,100000000);
INSERT 0 100000000
postgres=# ANALYSE test;
ANALYZE

Di default PostgreSQL ha max_parallel_workers_per_gather impostato a 2, per cui verranno attivati due worker durante un sequential scan.

Un semplice sequential scan non presenta novità alcuna:

postgres=# EXPLAIN ANALYSE SELECT * FROM test;
                                                       QUERY PLAN                                                       
------------------------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..1442478.32 rows=100000032 width=4) (actual time=0.081..21051.918 rows=100000000 loops=1)
 Planning time: 0.077 ms
 Execution time: 28055.993 ms
(3 rows)

È infatti richiesta la presenza di una clausola WHERE per la parallelizzazione:

postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i=1;
                                                       QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..964311.60 rows=1 width=4) (actual time=3.381..9799.942 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on test  (cost=0.00..963311.50 rows=0 width=4) (actual time=6525.595..9791.066 rows=0 loops=3)
         Filter: (i = 1)
         Rows Removed by Filter: 33333333
 Planning time: 0.130 ms
 Execution time: 9804.484 ms
(8 rows)

Possiamo tornare al comportamento precedente e osservarne le differenze impostando max_parallel_workers_per_gather a 0:

postgres=# SET max_parallel_workers_per_gather TO 0;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i=1;
                                               QUERY PLAN
--------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..1692478.40 rows=1 width=4) (actual time=0.123..25003.221 rows=1 loops=1)
   Filter: (i = 1)
   Rows Removed by Filter: 99999999
 Planning time: 0.105 ms
 Execution time: 25003.263 ms
(5 rows)

Un tempo 2.5 volte maggiore.

Non sempre il planner considera un sequential scan parallelo la migliore opzione. Se la query non è abbastanza selettiva e ci sono molte tuple da trasferire, è possibile che sia preferito un sequential scan "classico":

postgres=# SET max_parallel_workers_per_gather TO 2;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i<90000000;
                                                      QUERY PLAN
----------------------------------------------------------------------------------------------------------------------
 Seq Scan on test  (cost=0.00..1692478.40 rows=90116088 width=4) (actual time=0.073..31410.276 rows=89999999 loops=1)
   Filter: (i < 90000000)
   Rows Removed by Filter: 10000001
 Planning time: 0.133 ms
 Execution time: 37939.401 ms
(5 rows)

Infatti, se proviamo a forzare un sequential scan parallelo, otteniamo un risultato peggiore:

postgres=# SET parallel_tuple_cost TO 0;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i<90000000;
                                                             QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..964311.50 rows=90116088 width=4) (actual time=0.454..75546.078 rows=89999999 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on test  (cost=0.00..1338795.20 rows=37548370 width=4) (actual time=0.088..20294.670 rows=30000000 loops=3)
         Filter: (i < 90000000)
         Rows Removed by Filter: 3333334
 Planning time: 0.128 ms
 Execution time: 83423.577 ms
(8 rows)

Possiamo incrementare il numero di worker fino a raggiungere max_worker_processes (default: 8). Ripristiniamo il valore di parallel_tuple_cost vediamo quello che accade aumentando max_parallel_workers_per_gather a 8.

postgres=# SET parallel_tuple_cost TO DEFAULT ;
SET
postgres=# SET max_parallel_workers_per_gather TO 8;
SET
postgres=# EXPLAIN ANALYZE SELECT * FROM test WHERE i=1;
                                                       QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..651811.50 rows=1 width=4) (actual time=3.684..8248.307 rows=1 loops=1)
   Workers Planned: 6
   Workers Launched: 6
   ->  Parallel Seq Scan on test  (cost=0.00..650811.40 rows=0 width=4) (actual time=7053.761..8231.174 rows=0 loops=7)
         Filter: (i = 1)
         Rows Removed by Filter: 14285714
 Planning time: 0.124 ms
 Execution time: 8250.461 ms
(8 rows)

Nonostante PostgreSQL potesse usare fino a 8 worker, ne ha instanziati solo 6. Questo perché Postgres ottimizza il numero di worker anche in base alle dimensioni della tabella e al parametro min_parallel_relation_size. Il numero dei worker messi a disposizione da postgres si basa su una successione geometrica di ragione 3 il cui primo termine è min_parallel_relation_size. Facciamo un esempio. Considerando gli 8MB del default del parametro:

Dimensione Worker
<8MB 0
<24MB 1
<72MB 2
<216MB 3
<648MB 4
<1944MB 5
<5822MB 6

Possiamo vedere che, essendo la nostra tabella 3458MB, 6 è il massimo numero di worker disponibili.

postgres=# \dt+ test
                    List of relations
 Schema | Name | Type  |  Owner   |  Size   | Description
--------+------+-------+----------+---------+-------------
 public | test | table | postgres | 3458 MB |
(1 row)

Per concludere, una breve dimostrazione dei miglioramenti ottenuti da attraverso questa patch. Lanciando la nostra query abilitando un numero crescente di worker, otteniamo i seguenti risultati:

Worker Tempo
0 24767.848 ms
1 14855.961 ms
2 10415.661 ms
3 8041.187 ms
4 8090.855 ms
5 8082.937 ms
6 8061.939 ms

Possiamo vedere che i tempi migliorano notevolmente, fino ad arrivare ad un terzo del valore iniziale. È semplice da spiegare anche il fatto che non ci siano miglioramenti fra l’uso di tre e 6 worker: la macchina su cui è stato eseguito il test ha 4 cpu disponibili, per cui dopo 3 worker più il processo originale i risultati si stabilizzano.

Per concludere, con la 9.6 PostgreSQL ha posto le basi per la parallelizzazione delle query, di cui il sequential scan parallelo è solo il primo, ottimo, risultato. Vedremo infatti come sempre nella 9.6 siano state parallelizzate anche le aggregazioni, ma questo è materiale per un altro articolo che uscirà nelle prossime settimane.

lunedì, 20 giugno

10:30

Backup concorrenti con Barman e PostgreSQL 9.6 [2ndQuadrant]

Postgres-9.6+b PostgreSQL 9.6 estende il framework disponibile per i backup fisici permettendo agli utenti di eseguire backup in modo concorrente. Barman supporterà questo nuovo set di funzioni in modo trasparente, senza più richiedere l’estensione pgespresso.

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!

lunedì, 23 maggio

11:00

Rilasciato Barman 1.6.1 [2ndQuadrant]

2ndQuadrant è orgogliosa di annunciare la release 1.6.1 di Barman, il tool per il Backup e la Recovery Manager di PostgreSQL.

Questa minor release consolida il ruolo centrale di Barman nelle installazioni di business continuity di database PostgreSQL e ora permette agli utenti di implementare i comandi per il restore remoto in parallelo su server in standby e durante la recovery.

Inoltre, attraverso il nuovo comando ‘replication-status’, Barman diventa uno strumento molto pratico per il monitoraggio della replica in streaming di ogni server che gestisce.

Sono stati implementati anche altri importanti miglioramenti e sono state effettuate alcune correzioni di bug minori. Per maggiori informazioni, leggi l’annuncio completo oltre all’articolo in inglese scritto dal nostro Gabriele ‘Waiting for Barman 1.6.1‘.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery. Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup. Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

mercoledì, 20 aprile

18:49

pgAdmin 4 [:: Luca Ferrari ::]

C'è molto fermento ed eccitazione dopo l'annuncio che la versione 4 del famoso tool specifico per la gestione di un cluster PostgreSQL è vicina alla meta!
Come già anticipato un paio di anni fa, questa versione abbandona le wxWidget per lasciare spazio a Python e web frameworks, in modo da offrire maggiore flessibilità.
Con l'occasione gli autori hanno rivisto l'intera UI per migliorare l'esperienza di utilizzo del prodotto. Inutile dire che non vedo l'ora di provarlo!

lunedì, 11 aprile

21:38

Livelli di sicurezza in PostgreSQL [:: Luca Ferrari ::]

Può sembrare banale, ma Bruce Momjan ha pubblicato un corto e specifico post relativo ai livelli di sicurezza presenti in PostgreSQL, partendo dal rigetto delle connessioni al database fino alla sicurezza a livello di riga.
Consiglio a tutti la lettura.

sabato, 05 marzo

17:46

ITPUG @ Pycon sette [:: Luca Ferrari ::]

Grazie agli sforzi di alcuni soci volontari, una delegazione di ITPUG sarà in "missione" alla Pycon 7, la famosa e conosciuta conferenza italiana sul linguaggio di programmazione Python.

https://www.pycon.it/it/

Per il programma della conferenza vedere qui, mentre per i talk PostgreSQL cercare in particolare la track PyDatabase.

martedì, 01 marzo

09:40

Proroga scadenza della Call for Paper per la Conferenza 5432…MeetUs! [2ndQuadrant]

Il termine per la partecipazione con l’invio di un abstract alla Conferenza 5432…MeetUs! è stato prorogato alle ore 23:59 del 14 marzo 2016.

La seconda edizione del 5432… MeetUs! si terrà a Milano, il 28 e 29 giugno 2016.

Se ancora non hai risposto alla “Call for Paper”, sei ancora in tempo!topics-it

Tante le proposte pervenute, alcuni Ospiti e Testimonial di PostgreSQL hanno già confermato la loro presenza. I primi sponsor stanno già dando il loro supporto alla Conferenza.

E tra gli speaker che saranno selezionati potresti esserci proprio tu!

Ti rinnoviamo l’invito: se stai realizzando qualcosa di interessante con PostgreSQL, ti invitiamo ad inviarci una proposta di talk!

La proposta deve contenere un abstract che racconti gli aspetti fondamentali ed i punti salienti del talk che vorresti presentare, una breve biografia correlata di fotografia e i dati dei social ed email che vuoi rendere pubblici.

Topics

  • Sistemi operativi
  • Container
  • Hardware e benchmark
  • Configuration manager
  • Devops
  • Sistemi di monitoraggio
  • Virtualization tool
  • GIS
  • PostGIS
  • Continuous integration
  • Linguaggi di programmazione
  • Ricerca e insegnamento con PostgreSQL
  • Derivati e fork commerciali
  • Cloud Integrazioni con altri software
  • Migrazioni da altri database
  • Modello di business open source
  • Casi di studio
  • Hosting

Non aspettare troppo! Inviaci la tua proposta di talk!

lunedì, 29 febbraio

11:39

Rilasciato Barman 1.6.0 [2ndQuadrant]

2ndQuadrant è orgogliosa di annunciare il rilascio della versione 1.6.0 di Barman, “Backup And Recovery Manager” per istanze PostgreSQL. Questa nuova release introduce il supporto allo streaming dei WAL file, migliorando drasticamente la sicurezza delle soluzioni di backup per PostgreSQL basate su Barman e riducendo il Recovery Point Objective (RPO) quasi a 0. Per un corretto funzionamento, Barman necessita ancora dell’archiviazione tramite archive_command di PostgreSQL. Questo limite è destinato a essere rimosso non appena barman sarà in grado di supportare i Replication Slot. Un’approfondita attività di refactoring ed una maggiore attenzione ai controlli, rendono Barman ancora più stabile e robusto. Vi consigliamo quindi di procedete con l’aggiornamento il prima possibile. Per una lista completa delle modifiche, vi invitiamo a leggere il comunicato ufficiale in lingua inglese.

Cos’è Barman

Barman (Backup And Recovery Manager per PostgreSQL) è un software open-source scritto in Python. Permette di eseguire backup remoti su più server in ambienti business critical e di supportare gli amministratori di database durante la fase di recovery. Le funzionalità più apprezzate di Barman sono: cataloghi di backup, backup incrementale, retention policy, backup remoto e recovery, archiviazione e compressione dei file WAL e backup. Barman è progettato, implementato e mantenuto da 2ndQuadrant Italia e distribuito secondo licenza GNU GPL 3.

martedì, 02 febbraio

10:18

PostgreSQL 9.5 accorcia le distanze! [2ndQuadrant]

Il 7 gennaio è stata rilasciata la versione 9.5.0 di PostgreSQL! Quale migliore occasione per continuare a testare le nuove funzionalità introdotte.

mappe

Già nel mio precedente articolo sui BRIN ho evidenziato le novità introdotte soprattutto in ambito geospaziale con la 9.5. Oggi mostrerò una funzionalità della nuova versione di PostgreSQL che amplia ancora di più gli strumenti messi a disposizione in ambito GIS: la distanza punto-poligono, definita matematicamente come la minima delle distanze tra il punto di interesse e ciascun punto del poligono. Sebbene PostgreSQL abbia già nativamente introdotto alcune geometrie bidimensionali (point, circle, polygon, …), per poter calcolare la distanza di un punto da un poligono in 2D, fino ad oggi, era necessaria l’installazione di PostGIS (per esempio per trovare i punti di interesse più vicini ad un dato perimetro, o viceversa). Con PostgreSQL 9.5 non sarà più strettamente necessaria l’installazione di PostGIS (per quanto utilissima in ambito GIS) per questo tipo di operazioni.

La patch per il calcolo delle distanze tra point e polygon è stata introdotta da Alexander Korotkov, nome già noto nel mondo PostgreSQL soprattutto per i suoi lavori sugli indici GiST. Alexander ha implementato un algoritmo che iterativamente calcola la distanza del punto dai singoli segmenti, per poi prenderne la minima; tecnicamente, ha esteso l’overloading dell’operatore <-> in modo che non fosse limitato al calcolo della distanza fra coppie di geometrie dello stesso tipo point o polygon.

Cerchiamo di capire con un piccolo esempio come funziona, utilizzando uno script che permette di creare 10 milioni di quadrati con lato di lunghezza unitaria uniformemente distribuiti sul piano. La creazione della tabella sul mio desktop è stata completata in circa 13 minuti. Cerchiamo adesso quali sono i 10 quadrati più vicini all’origine (ovvero il punto di coordinate x=0, y=0), ossia facciamo una ricerca di tipo “the k nearest neighbours” (kNN):

SELECT point(0., 0.) <-> polygons AS distance
FROM polygons
ORDER BY distance DESC
LIMIT 10;

L’esecuzione della query ha richiesto, sul mio desktop, circa 17 secondi. Il piano di esecuzione prevede ovviamente un sequential scan di tutta la tabella per la ricerca:

QUERY PLAN    --------------------------------------------------------------------------------------------------------------------------------------
    -
     Limit  (cost=505032.60..505032.62 rows=10 width=101) (actual time=16505.291..16505.976 rows=10 loops=1)
       ->  Sort  (cost=505032.60..530032.69 rows=10000035 width=101) (actual time=16504.416..16504.420 rows=10 loops=1)
             Sort Key: (('(0,0)'::point <-> polygons)) DESC
             Sort Method: top-N heapsort  Memory: 26kB
             ->  Seq Scan on polygons  (cost=0.00..288935.44 rows=10000035 width=101) (actual time=0.533..13198.879 rows=10000000 loops=1)

Uso degli indici

La patch di Alexander introdotta in PostgreSQL non prevede il supporto per gli indici GiST per l’operatore <-> in ricerche kNN tra point e polygon: proviamo ad esempio a costruire l’indice sui polygon (sul mio desktop l’indicizzazione ha richiesto circa 30 minuti):

CREATE INDEX gist_index
ON polygons
USING gist(polygons);

Rilanciamo la stessa ricerca “nearest neighbours” di prima:

SELECT point(0., 0.) <-> polygons AS distance
FROM polygons
ORDER BY distance DESC
LIMIT 10;

Il tempo di esecuzione è stato nuovamente di 17 secondi, gli stessi del caso in assenza di indici. Infatti se andiamo a vedere quale è stato il piano di esecuzione troveremo che nuovamente è stata eseguita una sequential scan:

QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
    -
     Limit  (cost=505031.61..505031.63 rows=10 width=101) (actual time=15284.445..15285.214 rows=10 loops=1)
       ->  Sort  (cost=505031.61..530031.62 rows=10000006 width=101) (actual time=15283.761..15283.765 rows=10 loops=1)
             Sort Key: (('(0,0)'::point <-> polygons)) DESC
             Sort Method: top-N heapsort  Memory: 25kB
             ->  Seq Scan on polygons  (cost=0.00..288935.08 rows=10000006 width=101) (actual time=0.236..12805.262 rows=10000000 loops=1)

Conclusioni

PostgreSQL 9.5 ha introdotto la possibilità di effettuare ricerche kNN anche tra point e polygon sul piano, senza necessariamente installare PostGIS. Sebbene le ricerche kNN tra point o circle supportano l’indice GiST, ad oggi ciò non è possibile per quelle miste, tra point e polygon, in quanto richiedono una ricerca basata sul sequential scan completo dei dati.

Questa situazione sta per essere risolta. Alexander ha già presentato una patch in cui vuole introdurre una modifica degli indici GiST per supportare ricerche del tipo kNN-GiST with recheck [1] tra geometrie miste. Questo dovrebbe, tra le altre cose, rendere l’indice GiST utilizzabile anche per ricerche kNN tra point e polygon.


  1. Le ricerche di tipo “kNN-GiST with recheck” sono state incluse in PostgreSQL 9.5, ma non quelle tra geometrie miste. Con tutta probabilità la patch che contiene questa funzionalità verrà inclusa in PostGIS, piuttosto che in PostgreSQL. 

mercoledì, 27 gennaio

10:57

Seconda edizione di “5432… MeetUs!” – La call for paper è aperta! [2ndQuadrant]

Si terrà a Milano, il 28 e 29 giugno, la seconda edizione del 5432… MeetUs!

L’occasione di condividere le proprie esperienze con PostgreSQL e non solo. Una full immersion di due giorni, con l’opportunità di incontrare alcuni dei maggiori esperti, di ascoltare le testimonianze dirette di aziende che lo hanno adottato e di interagire con chi ha fatto di PostgreSQL la propria mission. topics-it Grande novità di questa edizione è l’apertura a nuovi argomenti: non si parlerà solo di PostgreSQL ma anche di tecnologie con cui PostgreSQL è coinvolto.

Se stai realizzando qualcosa di interessante con PostgreSQL, ti invitiamo ad inviarci una proposta di talk!

La proposta deve contenere un abstract che racconti gli aspetti fondamentali ed i punti salienti del talk che vorresti presentare, una breve biografia correlata di fotografia e i dati dei social ed email che vuoi rendere pubblici.

Topics

  • Sistemi operativi
  • Container
  • Hardware e benchmark
  • Configuration manager
  • Devops
  • Sistemi di monitoraggio
  • Virtualization tool
  • GIS
  • PostGIS
  • Continuous integration
  • Linguaggi di programmazione
  • Ricerca e insegnamento con PostgreSQL
  • Derivati e fork commerciali
  • Cloud Integrazioni con altri software
  • Migrazioni da altri database
  • Modello di business open source
  • Casi di studio
  • Hosting

 

Il calendario della call for paper è il seguente:

  • 16 gen 2016 – apertura della call for paper
  • 28 feb 2016 – chiusura della call for paper
  • 20 mar 2016 – la commissione tecnica informerà l’organizzazione sui talk accettati
  • 31 mar 2016 – gli organizzatori invieranno i responsi a tutti coloro che hanno inviato la loro proposta di talk
  • 31 mar 2016 – verrà pubblicato il calendario della conferenza

Non esitare, inviaci la tua proposta!

lunedì, 26 ottobre

21:49

ITPUGLab @ PGDay.IT 2015 [:: Luca Ferrari ::]

I had the opportunity and pleasure to play an active role in the third ITPUGLab, a well established tradition and a successful event me and my friend Gianluca proposed a few years ago.
And I have to say: it was really fun and educative.

What is the ITPUGLab? In short: it is an Open Space container entirely focused on PostgreSQL.
Attendees meet for exchanging, proposing or requesting ideas, thoughts, approaches and experiences getting 'hands-on' in a LAN environment and building a constructive shared experience on their laptops, or even philosophical discussions of any kind all being user-experience centric and related to PostgreSQl. No matter what the participants' skill level is.
There are no predefined contents: attendees come and propose or join others' proposals.
The evolution of the shared interactive contributions is what leads to discovering a path (not necessarily the right one) and get to a possible goal.
This translates to human-networking with a  PostgreSQL-social approach, allowing attendees to get acquainted in ways one cannot predict.

This year we had two and half hours dedicated to the lab, a very comfortable room and very nice people attending.

The following is the list of topics discussed end experienced:
  • installation on Microsoft Windows, where the users challenged the differences on installing PostgreSQL on a Unix-unlike machine, coming to the goal of providing a running instance to other people in the room;
  • migration and upgrade, with particular interest to the migration of a quite old cluster from a MS Windows machine to a mature and up-to-date cluster on a *nix machine, as well how to do it automatically and error-safely;
  • install, configure and use the PostGIS extension from scratch;
  • pl/pgsql scripting, with particular focus on editors, repos and best practices;
  • data integrity check and validation with regard to the database and/or application;
  • periodical data dump and load from one server to one (or many) others, with regard to various scenarios and possible automations.

Rules in the ITPUGLab are simple: after introducing themselves, participants start grouping spontaneously, warm up and get discussing, hands-on. Everybody can join a formed OpenSpace as well as leave it or, even, the room. When it's over, it's over: once the time elapsed pencil are down, and what happened is always the only and rightmost thing could happened.
Pictures cannot provide the excitement and fun filling the room.






As said, this is the third edition of the ITPUGLab, and quite frankly I'm proud of the continuous success it is getting within the PGDay.IT annual conference.
One thing all the three edition did have in common is the same request by attendees for more time: we are evaluating how to extend the session in the next PGDay.IT.
If you are coming to the next PGDay.IT, get into the lab: it's an experience you really don't want to miss!

sabato, 24 ottobre

15:38

PGDay.IT 2015: nine editions and counting! [:: Luca Ferrari ::]

pgday_200x60_it

We made it!
ITPUG (Italian PostgreSQL Users' Group) organized the ninth edition of the Italian PGDay, namely PGDay.IT.
We have a very strong a quite long tradition in organizing this national conference, and as in previous editions, we had a successful conference even this year.
The location, the Camera di Commercio di Prato, was simply great: a modern and really beautiful context to host the two tracks and the third edition of the ITPUGLab, the Open Space container entirely dedicated to PostgreSQL.
The keynote speech was performed by the well known community member Andres Freund, but he was not the only member of the international community.
After the keynote and the usual coffee break, with many delicious Italian pastries, the conference split in two parallel tracks where a set of very competent and efficient speakers  presented new projects, ideas, features and core implementations of our favorite database.
In the afternoon another track added to the already mentioned two giving the possibility to attendees to participate to the ITPUGLab, another well established tradition of the PGDay.IT.
Last but not least, the usual session of lightning talks, the group picture and the very good beer offered by one of the conference sponsor.

At the end we can count one hundred attendees, ten regular talks, sixteen speakers, six sponsors and two social beers.

It is quite difficult to recap in a few lines what this event was and has been in the past edition. I can only say that if you are missing this conference you are missing a very technical event within a friendly environment and fun context

giovedì, 08 ottobre

00:22

PGDay.IT 2015: we are here! [:: Luca Ferrari ::]

The ninth edition of the Italian PGDay (PGDay.IT 2015) is really close, and ITPUG is proud to announce that the schedule is available on-line.
As in the previous editions we have a rich set of talks and contributions, as well as the third edition of the ITPUG's own Open Space named ITPUG-Lab.

Check out the official website at http://2015.pgday.it and see you soon at PGDay.IT 2015!

mercoledì, 07 ottobre

21:56

PgBabylon is here! [Denis Gasparin » Planet PostgreSQL]

PgBabylon is a user-land extension to PHP PDO and PDOStatement native classes that helps to deal with PostgreSQL types like JSON, Arrays, etc.

It provides conversion between PHP types and PostgreSQL types and simplifies usage of SQL clauses like IN.

//
// Example: insert a PHP array in a PostgreSQL JSON field
//
use \PgBabylon\PDO;

$arr = [
    "name" => "Mark",
    "age" => 39,
    "address" => "White street, 23",
    "town" => "London"
];

$s = $pdo->prepare("INSERT INTO my_table(json) VALUES (:json) RETURNING json");
$s->execute([
    ":json" => \PgBabylon\DataTypes\JSON($arr)
]);

$s->setColumnType('json', PDO::PARAM_JSON);
$r = $s->fetch(PDO::FETCH_MODE_ASSOC);

print_r($r);

// Output contains the JSON PostgreSQL column decoded as PHP Array:
//
//  array(
//      "name" => "Mark"
//      "age" => 39,
//      "address" => "White street, 23"
//      "town" => "London"
//  )
//
//

Go and clone it on GitHub or install using composer

lunedì, 28 settembre

18:07

PGDay.IT 2015: online i talk accettati [:: Luca Ferrari ::]

Ormai il PGDay.IT 2015 è vicinissimo, e la lista dei talk accettati è disponibile sul sito ufficiale dell'evento.
Il keynote speaker di questa edizione è affidato ad Andres Freund, un nome piuttosto noto nella comunità internazionale grazie al suo lavoro sul sistema di replication.

Io avrò l'onore e il piacere, per la seconda volta (terza nella storia di ITPUG), di partecipare all'ITPUG-Lab, un open space dedicato a PostgreSQL, grande motivo di aggregazione e fonte di ottimo successo nelle precedenti edizioni.

venerdì, 04 settembre

19:13

PostgreSQL: Ordinamento secondo l'ultima cifra [Il blog di Enrico Pirozzi - Postgresql]

In questa piccola tip andremo a vedere come ordinare secondo il valore dell'ultima cifra:

lascio il link del mio post su www.psql.it



sabato, 15 agosto

18:59

PGDay.IT 2015 - stiamo arrivando! [:: Luca Ferrari ::]

E anche questa volta stiamo organizzando la giornata nazionale dedicata a PostgreSQL, il PGDay.IT 2015



Sono molto contento di poter far parte dell'organizzazione, anche perché la scorsa edizione sono dovuto rimanere assente causa problemi personali.
Tante le novità di questa edizione, a partire dalla sede che si sposta (di poco) in una nuova location molto moderna e che promette molto bene: la Camera di Commercio di Prato.
Nel frattempo abbiamo pubblicato anche i banner per farci un po' di pubblicità, abbiamo già due sponsor di tutto rispetto e diverse proposte di talk sono state inviate.
Non resta che rimanere sintonizzati e partecipare all'evento!

mercoledì, 20 maggio

lunedì, 06 aprile

20:22

Benvenuto nuovo Planet PostgreSQL it ! [:: Luca Ferrari ::]

Come probabilmente ci si è già accorti, il planet PostgreSQL italiano ha cambiato look.
Non si tratta solo di una revisione estetica, bensì di una necessaria migrazione dell'intera infrastruttura. So è colta anche l'occasione per modificare l'implementazione, passando da un planet-planet ad un rawdog.
Un ringraziamento a Gianluca per l'impegno e la professionalità.
E buona scrittura!