Feeds

FeedRSSLast fetchedNext fetched after
2ndQuadrant XML 22:01, lunedì, 24 aprile 23:01, lunedì, 24 aprile
:: Luca Ferrari :: XML 22:01, lunedì, 24 aprile 23:01, lunedì, 24 aprile
Il blog di Enrico Pirozzi - Postgresql XML 22:01, lunedì, 24 aprile 23:01, lunedì, 24 aprile
Planet PostgreSQL – Denis Gasparin XML 22:01, lunedì, 24 aprile 23:01, lunedì, 24 aprile
PostgreSQL – Blog di Diego Cinelli XML 22:01, lunedì, 24 aprile 23:01, lunedì, 24 aprile

venerdì, 14 aprile

15:55

Dimensioni delle tabelle e dei dati dump di testo, qualche insignificante esperimento [:: Luca Ferrari ::]

Mi sono ritrovato per le mani una vecchia e obsoleta istanza PostgreSQL 8.4 piuttosto grossa, lo spazio disco del tablespace
risultava essere di circa 13 GB! Ho quindi preso spunto per fare una piccola indagine su cosa occupasse tanto spazio,
concentrandomi solo sulle relazioni (tabelle):


SELECT c.oid,nspname AS table_schema
, relname AS TABLE_NAME
, c.reltuples AS row_estimate
, to_char( pg_total_relation_size(c.oid)::real/(1024*1024), '99G999D99' ) AS MB
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE
relkind = 'r'
AND
nspname = 'public'
ORDER BY 4 DESC, 3 ASC;

Ebbene sono saltate subito all'occhio tre tabelle in particolari (nomi di fantasia):


  oid   | table_schema | table_name | row_estimate |     mb
---------+--------------+------------+--------------+------------
63740 | public | tab1 | 8.74153e+06 | 2.248,58
66161 | public | tab2 | 2.9728e+06 | 1.192,00
65032 | public | tab3 | 2.44735e+06 | 1.280,77

Come si nota queste tre tabelle superano di slancio ciascuna una occupazione di 1 GB, arrivando fino a 9 milioni di tuple circa!
Insomma, non una cosa eccezionale per PostgreSQL, ma sicuramente nemmeno una cosa di routine, e che comunque indica forse la necessità
di una riprogettazione o di un partitioning.
Comunque, le stesse tabelle su disco quando occuperebbero in formato testo?



% pg_dump -h localhost -U luca -t tab1 testdb > tab1.sql

Effettuando il dump, con molta pazienza, di quelle tre tabelle sopra indicate si ottiene che:


% ls -lh tab?.sql
-rw-r--r-- 1 luca luca 579M 2017-04-12 11:32 tab1.sql
-rw-r--r-- 1 luca luca 494M 2017-04-12 11:37 tab2.sql
-rw-r--r-- 1 luca luca 571M 2017-04-12 11:36 tab3.sql

e quindi lo spazio occupato all'interno di PostgreSQL risulta da 2 a 4 volte superiore allo spazio disco dei dati testuali.
Chiaramente questa non rappresenta una inefficienza di PostgreSQL, quanto una naturale esigenza del database di tenere i dati allineati,
avere le pagine dati (8kB) con spazio sufficiente per consentire aggiornamenti, ecc.


Se si effettua un vacuum full sulle tabelle di cui sopra si ottiene il seguente risultato:


> vacuum full verbose tab1;
...
0 index pages have been deleted, 0 are currently reusable.

ad indicare che il database era già "buono", e abbastanza compattato. Ovviamente i dati che PostgreSQL riporta sul numero di tuple e dimensione
dei dati sono rimaste invariate.

lunedì, 10 aprile

19:49

Considerazioni sul planet italiano di PostgreSQL [:: Luca Ferrari ::]

Ho fatto caso che ormai sul planet ufficiale dell'associazione ITPUG, ovvero www.planetpostgresql.it, sto scrivendo
sporadicamente solo io. Questo secondo me è un campanello di allarme: io non sono certo migliore o piu' bravo di altri
soci e componenti dell'associazione, ma questa assenza dell'associazione dal planet indica che forse non si crede piu'
in questo strumento. Il fatto però è che nemmeno sul planet ufficiale si leggono post di ITPUG, e quindi non è tanto
la piattaforma italiana ad essere trascurata, ma il sistema di pubblicazione di notizie e articoli in generale.


Tornando al planet italiano, è facile verificare che su un periodo abbastanza ampio gli unici post
aggregati sono miei, e spesso risultano a loro volta dei link ad altre notizie ed articoli:


  1. 6 Gennaio 2017
  2. 13 Gennaio 2017
  3. 18 Gennaio 2017
  4. 27 Gennaio 2017
  5. 3 Febbraio 2017
  6. 21 Febbraio 2017
  7. 23 Febbraio 2017
  8. 24 Marzo 2017 (a) e (b)
  9. 2 Aprile 2017
  10. 5 Aprile 2017 (a) e (b)
  11. 8 Aprile 2017

Possibile che in un periodo di circa 3 mesi ITPUG non abbia avuto nessuna notizia da pubblicare?
Perfino in questi giorni, dove si richiede la regolarizzazione della quota per l'anno 2017 in vista
dell'imminente assemblea ordinaria, non vi sono notizie a riguardo.


Il consiglio che mi sento di dare al futuro consiglio è quello di prendere una decisione in merito al planet: se non lo si
vuole aggiornare allora tanto vale "spegnerlo", ma se lo si mantiene (come è tradizione anche nell'ambiente PostgreSQL e non solo)
allora lo si deve popolare periodicamente.

sabato, 08 aprile

17:24

PostgreSQL ltree [:: Luca Ferrari ::]

Da un thread su una delle mailing list ufficiali ho appreso di un tipo di dato a me sconosciuto: ltree.
Un ltree rappresenta un label tree, quello che nei linguaggi di programmazione è un meccanismo di properties. In sostanza
si definiscono delle etichette, ordinate gerarchicamente in base ad un separatore (il carattere .) e a queste si associa un valore.
Esistono poi funzioni apposite di utilità per la navigazione e la ricerca nell'albero delle etichette.


Vediamo un esempio pratico: supponiamo di voler catalogare in un albero alcune informazioni basilari riguardo la nostra associazioni
(dati assolutamente casuali e a puro scopo didattico!).


CREATE TABLE 
itpug( tipologia ltree, counter integer );

Ora si supponga di voler trovare il dettaglio dei soci, magari la loro somma partendo dalla foglia dell'albero:


SELECT sum( counter )  
FROM itpug  
WHERE tipologia @> 'itpug.soci';
sum
----
50
(1 row)


Supponiamo di voler trovare tutte le informazioni relativi al web (si noti l'uso della tilde):



SELECT *  
FROM itpug  
WHERE tipologia ~ '*.web.*';
tipologia | counter
---------------------------+---------
itpug.web.siti | 3
itpug.web.ssl.certificati | 1
(2 rows)


Insomma, ltree si presenta come estensione sicuramente interessante, anche se forse un po' sorpassata dall'uso di altri formati quali json e jsonb.

mercoledì, 05 aprile

22:28

Planet PostGIS [:: Luca Ferrari ::]

Scopeto da poco e quasi per caso: il planet.postgis.net è il planet ufficiale dell'estensione spaziale di PostgreSQL. La sua funzione è simile a quella del planet ufficiale di PostgreSQL: aggregare notizie ed esperienze da blogger di tutto il mondo relativamente al solo ambito GIS.
Non è sicuramente uno dei planet che leggerò quotidianamente, ma vale la pena tenerlo presente per avere un'idea dell'evoluzione del mondo GIS legato all'ecosistema PostgreSQL.

21:17

if-else in psql [:: Luca Ferrari ::]

Un articolo interessante che punta ad un commit di Tom Lane (e altri) per l'introduzione in psql di un costrutto if-else, ovvero \if, \elif, \else.
Mi torna subito alla mente Larry Wall in Programming Perl: soltanto un Algol-er potrebbe usare una parola chiave che è file scritto al contrario.
Ad ogni modo la modifica, che verrà introdotta con PostgreSQL 10, permette l'uso di costrutti condizionali basilari in psql. Si presti attenzione
che questi non sostituiscono i costrutti condizionali di plpgsql, ma si inseriscono direttamente nell'interprete SQL base fornito a corredo di
praticamente ogni installazione.
Sarà quindi possibile realizzare script automatici piu' complessi da dare in pasto al nostro fidato amico psql.

domenica, 02 aprile

18:15

Pipeline di una query in PostgreSQL [:: Luca Ferrari ::]

Una interessante spiegazione da parte di Tom Lane sulla pipeline di una query.
Anche se si fa riferimento all'utilizzo, non ammesso dallo standard SQL, degli alias SELECT in una clausola WHERE, la mail spiega in modo molto dettagliato come devono essere valutati
i vari passi della sintassi di una query.

venerdì, 24 marzo

19:08

Caratteri, codifiche, ordinamento [:: Luca Ferrari ::]

Un articolo molto chiaro e sintetico che aiuta a tenere a mente i concetti dietro collation, charater encoding e charset.
Consiglio vivamente la lettura.

18:30

SpeakerFight & PGDay.IT: è possibile? [:: Luca Ferrari ::]

Sono venuto a conoscenza per caso di un progetto interessante: SpeakerFight.
L'idea è abbastanza semplice, e l'implementazione mantiene la semplicità: si inviano dei contributi di talk (per conferenze ed eventi) e si lascia che le persone li votino, in un meccanismo stile "star" ben noto da altre piattaforme. I talk/contributi che hanno ricevuto il maggior numero di voti vengono selezionati per l'evento.

Un paio di giorni fa ho proposto di valutare questo meccasnimo nell'ambito del PGDay.IT. Da tempo sono sostenitore di una call-for-papers piu' aperta e con selezione maggiormente trasparente rispetto a quanto è avvenuto nelle ultime edizioni. Anzi, a dire il vero ho anche proposto piu' volte di fare un "speaker fight" del poveraccio addirittura per il keynote, proponendo di chiedere alla community chi fosse interessato a fare un keynote speech invece che andare su singolo invito diretto.

Ora sistemi come quello qui descritto hanno, ovviamente, i loro svantaggi: per esempio si potrebbe votare molto un talk tenuto da un perfetto incompetente che risulterebbe in uno speech di pessima qualità, trascurando magari talk meno "accattivanti" ma di sicuro successo ed impatto.
E forse alcune persone non vogliono selezionare di propria volontà i talk, quanto lasciare che siano gli organizzatori a "stupirli" con contenuti all'altezza di stimolare la curiosità e l'intelletto.
Tuttavia è difficile rimanere in un ambito o nell'altro se non si hanno dati alla mano circa il gradimento delle precedenti edizioni (questione che spesso ho sollevato).

Personalmente ritengo che aprire almeno una porzione del PGDay.IT ad un sistema di votazione diretta possa dare quella spinta ad autori e partecipanti per sentirsi maggiormente coinvolti e, soprattutto, per poter decidere il livello dei contenuti da visionare, garantendo quindi una maggiore partecipazione (almeno in teoria).
Se poi il tutto viene accompagnato anche da un feedback sui talk, si può avere una base dati abbastanza oggettiva che possa permettere un evento migliore ad ogni edizione.

Per sessioni interattive penso che un sistema di gradimento anticipato sia fondamentale: organizzare una sessione interattiva (es. ITPUG-Lab) non è semplice e rischia di portare via risorse (sia organizzatori che partecipanti) dalle track della conferenza. Occorre quindi essere certi del gradimento e della partecipazione alla sessione.

Insomma, una sfida interessante e uno spunto per i prossimi organizzatori dell'evento perché si possa sempre migliorare e non "sedimentare" su formule sempre uguali e ripetute.

giovedì, 23 febbraio

22:22

Quali parte sono "colpite" dalle statistiche PostgreSQL? [:: Luca Ferrari ::]

Ecco una interessante immagine che rende l'idea di quali parti del complesso e completo sistema di statistiche PostgreSQL. L'immagine mostra quali viste usare a seconda della parte di backend/stack che si vuole monitorare.
Per l'articolo originale si veda qui:


martedì, 21 febbraio

17:12

PostgreSQL @ Python [:: Luca Ferrari ::]

Il legame tra Python e PostgreSQL appare sempre piu' forte.
Se da un lato ITPUG sarà anche per questa edizione media partner della conferenza italiana PyCon 8 , la community PostgreSQL viene citato nella sezione Community per l'internazionale PyCon 2017.

venerdì, 03 febbraio

17:55

GitLab, PostgreSQL, e la perdita accidentale dei dati [:: Luca Ferrari ::]

Un socio di ITPUG ha indicato un articolo interessante riguardante un incidente informatico capitato a GitLab. A parte il tecnicismo e l'errore, forse grossolano e sicuramente dettato dallo stress e la fretta (chi è senza peccato scagli la prima pietra...), la parte interessante dell'articolo è l'apertura e la documentazione che GitLab ha voluto fornire a seguito dell'accaduto.
Sicuramente questo atteggiamento ha permesso a GitLab di uscire "meglio" dal disastro, poiché quasi tutti gli sviluppatori hanno apprezzato la documentazione fornita, che ha consentito uno studio postumo utile a chi si troverà in simili situazioni.

venerdì, 27 gennaio

21:08

TAP: alcuni concetti [:: Luca Ferrari ::]

Il Test Anything Protocol (TAP per gli amici) è un formato semplice ed efficace per la reportistica di test automatici.
Nato nell'ecosistema Perl nel 1988, il protocollo si è evoluto ed è uscito dai confini Perl per giungere ad altri linguaggi e sistemi, perfino database con PostgreSQL e pgTap.

Il formato TAP è abbastanza semplice e si basa su alcuni concetti semplice:
  • producer è un'applicazione che si occupa di produrre un output TAP compatibile (su stdout)
  • consumer è un'applicazione che si occupa di interpretare l'output di un producer e fornire un report finale.

Ad esempio "prove" è un consumer dell'output prodotto da "Test::More" e similari, che a sua volta fungono da producer.
Nell'esempio relativo a PostgreSQL si ha che "pg_prove" è un consumer, e le funzioni importate da pgTap e i relativi script SQL sono i producer.

Il formato TAP è abbastanza semplice e prevede un solo paio di elementi obbligatori.
Anzitutto occorre inserire il numero di test, ovvero il piano di esecuzione, indicato come 1..N (con N > 0), e solitamente questo compare come primo elemento nell'output. Grazie a questa informazione il consumer sa se ha raggiunto la fine dei test (N) correttamente o se qualcosa ha causato un abort del sistema. Con l'evoluzione TAP supporta anche che N sia zero, indicando così che si vuole saltare la porzione di test. Inoltre è possibile specificare il piano di esecuzione alla fine, che in altre parole è come dire che non c'è un vero piano di esecuzione.

Successivamente, per ogni test effettuato, ci deve essere almeno una riga che inizia con "ok" oppure "not ok". Questo è l'unico elemento obbligatorio, anche se altri sono suggeriti per una migliore comprensione e analisi dei tool consumer.
Subito dopo lo stato del test si dovrebbe indicare il numero progressivo del test stesso, come pure una descrizione del test (affinché si possa capire meglio quale test è stato eseguito). Da ultimo vi è la possibilità di una direttiva (commentata in stile Perl, ossia con "#") che può indicare di saltare il test (SKIP) o che il test non è ancora completo (TODO).

Riassumento l'output di TAP può essere considerato come:


<# direttiva>

Ed ecco quindi un esempio pratico:

1..2
ok 1 - First comparison test
ok 2 - Second comparison


Qualora il piano di esecuzione non sia corretto TAP dovrebbe fornire una indicazione (non una direttiva) di tale fatto:

1..10
ok 1 - First comparison test
ok 2 - Second comparison
# Looks like you planned 10 tests but ran 2.

Solitamente durante la fase di sviluppo non si utilizza un piano di esecuzione, ma all'atto del rilascio del software il piano di esecuzione deve essere "congelato" in modo da aumentare la verifica automatica di errori.


Nell'output di TAP tutte le linee che iniziano con un commento in stile Perl ("#") vengono ignorate e usate, ad esempio, per fornire all'utente dei messaggi diagnostici per aiutarlo a capire perché un test è fallito.

Una direttiva di emergenza, denominata "Bail out!", indica che il sistema di test ha deciso di non proseguire per errori (controllati) troppo gravi. Ad esempio si può annullare una sessione di testing perché la rete non è disponibile, o il compilatore non è alla versione corretta, ecc.

Nel caso in cui non sia fornito un vero piano di esecuzione, e quindi l'output di TAP non inizi con "1..N", il sistema non sa quanti test deve eseguire. In questa eventualità si deve procedere con i test, aumentando in modo incrementale l'eventuale numero riportato in uscita, e alla fine stampando il "presunto" piano di esecuzione:

ok 1 - First comparison test
ok 2 - Second comparison
1..2

Tuttavia in questo caso il sistema non può sapere autonomamente se i test sono finiti o se c'è stato un abort di esecuzione, e per questo si richiede al programmatore di inserire una chiamata di fine esecuzione (ad esempio in Perl done_tsting() ).


Fino a qui ci si è occupati di TAP dal lato del producer. L'output di TAP viene poi analizzato a sua volta da un consumer, ad esempio "prove" o "pg_prove" che forniscono un riassunto su quanti test sono stati eseguiti, quanti sono andati bene e quanti sono falliti. L'idea dei consumer è che, all'aumentare del numero di test, l'utente dovrebbe potersi concentrare solo sul risultato finale e non sui singoli output dei vari test.

Per maggiori informazioni sulle specifiche TAP si veda qui.

16:04

Reboot ITPUG (Le mie dimissioni da ITPUG...parte 3) [:: Luca Ferrari ::]

Il consiglio di ITPUG è nuovamente in forze: dopo le mie dimissioni di circa un mese fa è stato eletto un nuovo socio per sostituirmi.
Questo permetterà ad ITPUG di proseguire le normali attività fino alle prossime elezioni di fine biennio, direi Aprile.
Presto sparirà il mio nome dalla lista dei consiglieri , immagino ci vorrà tempo perché si dia la giusta visione al mio sostituto.

A seguito delle mie dimissioni ho assistito ad un approccio abbastanza roccambolesco nella gestione del da farsi. Premesso che non ho intenzione di polemizzare e che quanto qui descritto rappresenta solo (e ovviamente) il mio punto di vista, ecco cosa è successo.

Anzitutto un po' di delusione perché le mie dimissioni non sono nemmeno state verbalizzate. Non è mania di protagonismo, ma un consiglio che vuoel una gestione trasparente deve quanto meno prendere atto di quanto sta accadendo al suo interno e "scolpirlo" nella pietra. Amarezza anche per la presidenza, che nonostante io avessi chiesto si pronunciasse, si è limitata a convocare l'assemblea straordinaria.

Stupore anche per la decisione, quasi unilaterale e a colpi di rima baciata (ossia in modo molto prolisso), di delegittimazione del consiglio stesso. Essendone io uscito si è deciso, applicando in maniera molto rigida e forse non regolare lo statuto, di delegittimare il consiglio stesso. A nulla è servito portare alla memoria dei consiglieri (alcuni storici quasi quanto me) e dei soci che già in passato, in analoga situazione e con dimissioni presentate, il consiglio aveva comunque proseguito la sua attività. E a nulla è servito ricordare che anche i soci pendenti potevano essere ammessi all'associazione (anche perché lo statuto stesso prevede 30 giorni per una decisione).

I soci stessi sono stati posti in discussione, utilizzando una logica boolean abbastanza contorta per la quale chi non aveva pagato/rinnovato la quota 2017 risultava "non in regola" e quindi non ammesso alle votazioni del mio sostituto. Ora, in assenza di un regolamento specifico e considerato che le quote vengono rinnovate in occasione dell'assemblea ordinaria (solitamente Aprile), questa mi è sembrata una contromisura molto forte. Inoltre, non essendoci un termine stabilito per il rinnovo, definire la morosità dei soci risulta abbastanza discutibile.
E anche qui i consiglieri storici avrebbero potuto ricordarsi di cosa accaduto nel 2014, situazione differente ma valutazione di "morosità" analoga.
Ancora peggio: c'è la garanzia che i consiglieri fossero tutti in regola con la quota?
E se non lo erano, anche se per un breve periodo nel loro mandato, il consiglio non deve essere analogamente delegittimato?

Ma andiamo avanti. E' stata convocata una assemblea straordinaria dei soci, sbagliandone la convocazione e facendo quindi slittare di un giorno l'assemblea stessa. Che poi è stata verbalizzata come ordinaria, e non come straordinaria.
Piccolezze, sviste, e concordo! Ma una associazione che vuole applicare rigidamente lo statuto non può fare simili sviste, almeno secondo me.
E se anche succedono queste sviste, perché in un caso la convocazione è stata annullata (ritardando quindi la "rilegittimazione" del consiglio) e nell'altro caso no?

Insomma, come si evince, ritengo che sia stato applicato uno statuto mirato piu' a legare le mani all'associazioni che non a sostenere la stessa.
Fermo restando che l'approccio difensivo difficilmente risulta inadeguato, forse questo accanimento ha causato piu' danni che utile.

Detto questo penso, in tutta onestà, che a parte i miei impedimenti personali forse è un bene che io sia uscito da questo consiglio: le incongruenze fra il mio modo di vivere l'associazione e quello degli altri membri è ormai abbastanza distante, e questo avrebbe comunque impedito un sano lavoro di entrambi.

In bocca al lupo al nuovo consiglio, e buon lavoro!
Sperando che si riprenda a pubblicare ai soci i verbali delle riunioni, anche questi trattenuti a colpi di statuto...

Un'ultima nota: fino alle mie dimissioni io sono stato l'unico consigliere ad essere stato in carica dall'inizio dell'attività ITPUG con assoluta continuità. Ahimé ritengo che la mia memoria storica non sia stata utilizzata in modo costruttivo come avrebbe potuto.

P.S.
dai messaggi che passano in lista soci penso di sapere chi sarà il prossimo presidente: 47605db981f8

mercoledì, 18 gennaio

20:14

Quanto ITPUG? (Le mie dimissioni da ITPUG parte 2) [:: Luca Ferrari ::]

Avendo marcato la fine della mia attività da consigliere con le dimissioni di circa un mese fà, ho deciso, quasi per curiosità, di cercare di quantificare il lavoro svolto da ITPUG e dal suo consiglio negli ultimi due mandati.
Si tratta di dati ovviamente indicativi, visto che strumenti diversi offrono opzioni di statistica differenti, ma possono essere utilizzati per un grezzo lavoro di analisi quantitativa.
E' bene sottolinearlo: si parla di attività quantitativa, non qualitativa!
Tuttavia l'attività quantitativa spesso indica e sottointende la presenza in associazione e la vitalità della stessa, da qui il mio interesse per questi semplici dati.

Ovviamente non sto svelando alcun segreto, questi dati sono comunque visibili e calcolabili da ogni consigliere e socio, con un po' di impegno e pazienza. Potrei anche aver commesso qualche errore di computazione, nel qual caso ogni correzione è ben accetta.

Considerando quindi la data del 30 aprile come termine di un biennio (e il relativo inizio del successivo), e sottolineando come il biennio 2015-2017 non sia ancora giunto al termine (e quindi i dati di tali biennio si riferiscono alla data attuale), si ha che:
  • biennio 2013-2015
  1.  301 commits
  2. 281 tickets
  3. 19 verbali riunioni di consiglio
  4. 108 thread in lista itpug-consiglio@
  5. 170 thread in lista itpug-soci@
  • biennio 2015-2017
  1. 103 commits
  2. 190 tickets
  3. 7 verbali riunioni di consiglio
  4. 160 thread in lista itpug-consiglio@ 
  5. 130 thread in lista itpug-soci@

L'attività del consiglio può essere quantificata con il numero di commits nel repository documentale, ovvero quanti documenti il consiglio ha ritenuto di inserire fra quelli ufficiali (fra questi, i verbali delle riunioni di consiglio), nonché dal numero ti tickets (ovvero di problematiche e task da affrontare). Come si può notare il valore di entrambi è drasticamente calato nell'ultimo biennio, segno che non si utilizza piu' né il repository né il sistema di ticketing come strumento base per la gestione delle attività del consiglio.
Questo è in parte confermato anche dall'aumento del numero di thread nella mailing list consiglio, che rispecchia il maggior uso e preferenza di questo canale di discussione rispetto agli altri strumenti.
A mio avviso questa è una regressione, poiché l'email non rappresenta lo strumento ideale per gestire scadenze, priorità, condivione di documenti.
Il dato però piu' allarmante, a mio avviso, è quello delle riunioni di consiglio, o meglio, dei verbali delle riunioni di consiglio. Come si può vedere le riunioni di consiglio sono scese del 60% circa, segno che il consiglio non ritiene sufficientemente utile riunirsi con regolarità (ulteriore conferma della preferenza del canale e-mail), o ha delle difficoltà a riunirsi.
Appare anche diminuita l'attività e la presenza del consglio nella mailing list dei soci, visto che il numero di thread si è abbassato. Ora, questo dato in particolare non coinvolge direttamente il consiglio, visto che i thread possono anche essere creati dai singoli soci (e anzi, questo è quello che dovrebbe accadere); tuttavia l'abbassamento del numero di discussioni evidenzia, secondo me, un raffreddamento del "networking" fra i soci al quale il consiglio dovrebbe cercare di porre rimedio.

Lascio ad altri il computo dei post e della frequenza di aggiornamento del planet italiano perché sarei sicuramente male interpretato.

ITPUG ha una struttura di supporto informatico sicuramente complessa e funzionale (si veda qui), di gran lunga superiore a quella di molte altre associazioni PostgreSQL analoghe. Ritengo sia di vitale importanza per l'associazione che ogni consiglio riesca ad usare al meglio questa infrastruttura, nonché la storia che essa contiene (archivi, logs, ecc.) poiché rappresenta un bagaglio culturale di enorme valore.

venerdì, 13 gennaio

17:59

Josh Berkus lascia il core team di PostgreSQL [:: Luca Ferrari ::]

E' di ieri la notizia che Josh Berkus, uno dei membri del core-team di PostgreSQL, si dimette dal core team stesso, e in effetti come diretta e rapida conseguenza non appare piu' il suo nome nell'elenco dei contributor (si veda il suo annuncio ufficiale qui.

Ho avuto poche occasioni di vedere Josh dal vivo, e quello che mi ha sempre colpito è la sua capacità come speaker, oltre alle sue competenze tecniche dettate da una grande esperienza. Ma un'altra cosa mi ha sempre colpito: Josh si è sempre dimostrato (nelle sue apparizioni nonché nelle sue comunicazioni nelle varie mailing list) una persona corretta e aperta, in una sola parola mi ha sempre dato l'impressione di essere una persona "pura" per quanto riguarda il progetto stesso.
Questo perché, a differenza di altri membri del progetto, si sono viste anche reazioni molto piu' business-oriented e meno community-centric.

Ritengo che Josh abbia svolto un ruolo molto importante per l'advocacy e la qualità del progetto PostgreSQL e, anche se il team è composto da persone piu' che valide, penso sarà difficile rimpiazzare pienamente un simile personaggio.

venerdì, 06 gennaio

18:55

Le mie dimissioni da ITPUG [:: Luca Ferrari ::]

Cari soci,
anzitutto buon anno (anche se in ritardo)!
E' con dispiacere e un po' di imbarazzo che vi informo che qualche giorno addietro, precisamente prima di Natale, ho presentato le mie dimissioni dal ruolo di consigliere.
La mia partecipazione in ITPUG si è ridotta per cause esterne, e ultimamente mi trovo anche in difficoltà nel rappresentare l'associazione.
In considerazione di tutto ciò, sperando nel meglio per l'associazione, e senza voler occupare un ruolo in modo "sterile", mi faccio quindi da parte.

Preciso, qualora necessario, che dalla data della presentazione delle mie dimissioni mi sto astenendo da esprimere ogni opinione in consiglio, se non espressamente richiesto.

Ho seguito e servito ITPUG dalla sua costituzione, la ritengo una esperienza interessante ed utile, grazie anche a voi.

Ad ogni modo non vi sbarazzerete facilmente di me, e ci ritroveremo a conferenze e sui vari canali informatici come al solito!

Grazie,
Luca



Questa è la lettera che ho inviato nella mailing list soci di ITPUG per confermare le mie dimissioni dal ruolo di consigliere.
Niente di drammatico, né tanto meno melodrammatico, ma spero con questo mio post di poter chiarire meglio la situazione e la mia decisione, che sono certo potrà essere interpretata negativamente, molto piu' di quanto non lo sia.

La parola chiave di tutto questo è coerenza.
Coerenza con me stesso, con gli impegni presi, con l'associazione che ho contribuito a creare e che ho risollevato.
Non posso piu' onorare gli impegni presi, perché vicissitudine esterne ad ITPUG mi tengono lontano dall'associazione, e di questo ne sono mortificato.
Quindi, per coerenza con l'impegno preso, trovo corretto farmi da parte.
Ma c'è anche la coerenza con me stesso: io ho una visione della vita di associazione che, sicuramente per una mia interpretazione sbagliata, tende a stridere con quanto osservo ultimamente in ITPUG. In particolare se ripenso all'enorme impegno che mi ero assunto come presidente anni fà, quando sono riuscito a risollevare (non da solo!) sia l'associazione, prossima alla chiusura, che il PGDay.IT; entrambi versavano ormai in uno stato comatoso e sicuramente non open.

Come ho scritto brevemente sopra è stata una esperienza interessante, ma anche impegnativa. Sono passato attraverso molte soddisfazioni e anche molte delusioni, perfino interrogativi. Mi sono state rivolte belle parole e brutte parole, perfino azzardi su conflitti di interesse. Sorrido se ci ripenso, anche perché per me PostgreSQL non è mai stato piu' che un hobby, una passione. E anche perché, se ben ricordo, all'ultimo PGDay.IT al quale ho partecipato sono stato l'unico organizzatore a segnarsi come membro ITPUG invece che di una azienda, ente, università.

Ho sempre tentato di svolgere una attività sana e alla luce del sole, cercando di dare pari opportunità a tutti quanti. Ho sempre tentato di portare avanti il nome dell'associazione, facendola comparire anche nel planet.postgresql.org, sulle riviste per le quali scrivevo articoli, e nelle piccole interviste fatte.

Ho conosciuto molta gente interessante, molti stereotipi altrettanto interessanti e molte realtà aziendali ed enti che fanno duro lavoro per mantenere quello spirito open che mi ha sempre affascinato.

Ora, inutile farla tanto melodrammatica: non sarò stato infallibile, non sarò stato impeccabile, ma ho speso veramente tante energie per questa associazione, e il solo fatto che sia qui a scrivere a riguardo testimonia quanto sia stata per me una decisione difficile.

Perché anticipare le dimissioni visto che il consiglio sta per giungere alla sua "naturale" scadenza? Già, è una domanda lecita, sulla quale i maliziosi potranno lucrare teorie complottiste, ma la questione è realmente semplice come eseguire una rollback.
Il fatto è che non mi sento piu' di fare parte del consiglio, e avere senzazioni senza-azioni non è da me. Come dicevo, coerenza...

Cosa succederà adesso?
Beh, niente panico! ITPUG ha un consiglio formato da gente esperta che saprà portare avanti l'associazione. Dopotutto io non sono certo indispensabile!
E comunque mi rendo disponibile ad affiancare il consiglio qualora lo si riterrà opportuno.

mercoledì, 21 dicembre

11:10

PGDay.IT 2016 [2ndQuadrant]

img_6093-jpgAnche quest’anno si è svolto il PGDay, evento annuale organizzato dall’ITPUG, l’associazione italiana di PostgreSQL. Nonostante i membri dell’associazione siano sparsi per tutto il territorio nazionale, la decima edizione si è svolta nella città che ha dato i natali all’associazione ITPUG, Prato, la mia città.

Durante la manifestazione ho avuto il piacere di dare il mio contributo alla comunità, presentando un talk riguardo l’installazione di PostgreSQL su Network File System. Nel talk ho raccontato una mia esperienza professionale condivisa con il mio collega Giuseppe Broccolo, nel quale testavamo l’affidabilità di Postgres su NFS.

Condividere la mia esperienza su PostgreSQL con gli altri partecipanti all’evento è stato piacevole e costruttivo.

Ho potuto apprezzare i talk di Denis Gasparin sui diversi tool per l’upgrade tra major release di PostgreSQL oltre al keynote tenuto da Giorgio Roncolato, Direttore Sistemi Informativi ULSS 5 di Arzignano, sulla migrazione all’Open Source, dimostrando quanto i tempi siano maturi anche per le istituzioni, sempre più sensibili all’argomento Software Libero.

Come non menzionare i divertenti talk animati di Mladen Marinovic, coi quali è riuscito a trasmettere l’importanza del testing e della code review intrattenendo la platea e regalando momenti di ilarità.

Manifestazioni di questo tipo permettono la condivisione della conoscenza attraverso i dibattiti e le discussioni che nascono sia al termine di ogni talk che durante i momenti di networking.

L’evento mi ha dato l’oppurtunità di stringere nuove amicizie e di rafforzarne altre già confermate. La giornata si è conclusa con un aperitivo che ha portato ad uno scambio di opinioni, prolungando il tempo di permanenza di alcuni partecipanti.

martedì, 13 dicembre

14:47

PgDay.IT 2016: ci siamo (senza di me) [:: Luca Ferrari ::]

Oggi è la giornata del decimo PgDay.IT.
Sono passati già dieci anni dal primo evento organizzato da un gruppo di "ragazzotti" aggregati in un modo abbastanza disorganizzato ma efficace.
Io ne entrai a far parte per caso: era il 2007 e stavo iniziando un progetto importante basato su PostgreSQL, e così, cercando gruppi di discussione in italiano capitai sopra ad una rudimentale pagina wiki che parlava di un evento interamente dedicato a questo database.
Mandai quindi una mail di disponibilità e il gioco fù fatto: ero uno degli organizzatori dell'evento, il quale si dimostrò da subito molto importante per la comunità internazionale.
Da lì si formò ITPUG, l'associazione che nelle nove edizioni passate ha organizzato le altrettante versione dell'evento.

Quest anno, purtroppo, non potrò partecipare all'evento, per ragioni personali. Anche la mia partecipazione nell'organizzazione dell'evento è stata meno incisiva rispetto agli anni passati.

In generale però posso affermare di non essere stato l'unico ad aver contribuito in maniera ridotta a questo PgDay.IT, e l'impressione generale e che mi viene riportata è quella di un evento sottotono. Spero che l'organizzazione possa dimostrare il contrario; il programma e la partecipazione parlano da soli.

Ma il dispiacere piu' grande non è certo quello di non avere un evento colossale, quanto quello di non poter passare una giornata intera a parlare ed ascoltare le avventure di PostgreSQL, di non poter rivedere amici di conferenza (e non solo) e bere una buona birra in loro compagnia.

Ma ci saranno altri eventi, altre conferenze, altri PgDay.IT e altre birre per recuperare il tempo perso!

Buon evento a tutti.

martedì, 06 dicembre

17:29

PGDay.IT 2016: cena sociale [:: Luca Ferrari ::]

Ormai manca pochissimo al prossimo PGDay.IT 2016, ed è ora ufficiale che ci sarà anche la cena sociale, con una organizzazione meno formale rispetto agli anni passati.
Se volete unirvi al gruppo che tiene in vita la conferenza fatevi trovare la sera prima dell'evento presso il locale Camelot 3.0.

mercoledì, 30 novembre

19:09

PgDay.IT 2016: keynote [:: Luca Ferrari ::]

Il programma del PgDay.IT 2016 è ormai completo: anche il keynote che anora non era stato annunciato è stato posizionato.
Ad aprire la decima edizione della conferenza italiana dedicata a PostgreSQL sarà il dott. Giorgio Roncolato, attuale direttore dei Sistemi Informativi ULSS 5 di Arzignano, dove ovviamente viene usato massivamente PostgreSQL.

sabato, 26 novembre

09:55

pgrepup – upgrade PostgreSQL using logical replication [Planet PostgreSQL – Denis Gasparin]

pgrepup is a tool written in Python for upgrading a PostgreSQL cluster to a new major version using logical replication and pglogical extension.

pgrepup simplifies the setup of 2nd Quadrant’s pglogical extension giving hints for configuring correctly source and destination pgsql clusters.

The supported versions of PostgreSQL are 9.4, 9.5 and 9.6.

Quick start

Requirements

pgrepup requires both a source and a destination PostgreSQL cluster.

The clusters can have been installed into the same server or on different hosts.

pgrepup doesn’t need to be installed on the clusters’ server.
It can be safely executed from a remote host that can access both pgsql clusters. In this case, it’s recommended that SSL is enabled in pg_hba.conf of both clusters because pgsql credentials are sent over the network.

Installation

pip install pgrepup

All versions of Python >= 2.7 are supported.

Replication

A pgsql cluster can be replicated and upgraded using pgrepup following these four steps:

  1. pgrepup config
     : a simple wizard asks the basic configuration parameters needed by pgrepup
    • Source and Destination database cluster
    • Directory where to store temporary files
  2. pgrepup check
     : various checks are performed both in Source and Destination cluster
    • if a check fails, pgrepup outputs a hint for helping you to configure each cluster
  3. pgrepup setup
     : if the checks are all ok, this setup installs and configure pglogical in both pgsql clusters
  4. pgrepup start
     : start the replication process

After the start command, you can monitor the replication process using the command 

pgrepup status

The output of the status command displays an entry for each database of the source cluster along with the status reported by pglogical extension.
The status can be one of the following three values:

  • initializing
     : pglogical is copying data from source to destination cluster
  • replicating
    : pglogical is using pgsql logical replication to replicate and upgrade new data changed into the source cluster
  • down
    : replication is down, check the PostgreSQL log in both clusters

After issuing the start command all databases will be in the 

initializing
 status. During this phase pglogical background workers are executing the SQL dump of the source cluster, so it can take a while to complete.
When the dump is completed, each database status will change to 
replicating
 as the data is progressively copied from the source cluster.

Upgrade

When the replication is working fine, you can switch your application to the destination cluster at any moment.
Just follow these steps:

  • stop your application connecting to the source cluster
  • ensure no more connections are made to the source cluster
  • stop replication using 
    pgrepup stop
      command
  • change the DSN in your application (or in your connection pooler) and point to the destination cluster
  • start your application
  • upgrade done! 🙂

Caveats and limits

pgrepup is still experimental. Please feel free to open an issue on github if you encounter problems.

DDL commands

DDL commands issued in a source cluster database are not replicated to the destination cluster. This is a limit of how pgsql logical replication works.
Use the 

pglogical.replicate_ddl_command
  SQL function on the source database in order to replicate the DDL on the destination cluster.

Be aware that, at the moment, pgrepup doesn’t handle the automatic subscription of newly created tables added using 

pglogical.replicate_ddl_command
 .
The recommended procedure is to re-start the replication process using the stop, setup and start commands.

A solution is in the works and will be available in the next release of pgrepup.

Sequences

Sequences are replicated between source and destination cluster. When the stop command is given, pgrepup uses pglogical function to do a final synchronization of each sequence value.
The pglogical function adds an artificial +1000 value to the actual sequence value: see this discussion on pglogical mailing list on google groups.

High number of databases

After issuing a start command, pglogical background workers start all simultaneously to dump the data of the source database into the destination database.

This can generate very high cpu/disk load on both clusters depending on the number of databases to replicate.

A feature that enables to limit the number of databases that are dumped concurrently is in the works.

Contributions

pgrepup is licensed using GPL-3 license. Source code is available at project page on github: https://github.com/rtshome/pgrepup

Contributions are welcome!

venerdì, 25 novembre

11:39

PgDay.IT 2016: partner! [:: Luca Ferrari ::]

Ormai vicinissimo il PgDay.IT 2016 si arricchisce di diversi partner, e speriamo che presto altri allunghino la lista. Al momento si ha:

Partner Platinum
  • Interlogica
  • Esosphera
  • Miriade

Partner Silver
  • 2ndQuadrant Italia

venerdì, 11 novembre

18:52

PgDay.IT 2016: programma online! [:: Luca Ferrari ::]

Il programma del prossimo (e ormai vicinissimo) PgDay.IT 2016 (decima edizione) è online. Anche se potrebbe subire qualche variazione da parte degli organizzatori, il programma online rende l'idea dei talk e degli aspetti che saranno trattati nel prossimo evento.

E se si vuole cogliere l'occasione per farsi un po' di pubblicità attraverso il PgDay.IT 2016 perché non diventare sponsor?

18:42

PgDay.IT 2016: schedule is online! [:: Luca Ferrari ::]

The PgDay.IT 2016 is approaching and the schedule is available on line here. Of course it could be subject to some little changes, but it is pretty mich a complete list of what you are going to see at the tenth edition of the PostgreSQL Italian Day.

giovedì, 10 novembre

21:50

Interessante spiegazione di vacuum e autovacuum [:: Luca Ferrari ::]

Sembra quasi un argomento da novellino: PostgreSQL deve usare la procedura di vacuum per mantenere la struttura dati (su disco) pulita e ordinata, in altre parole efficiente.
La necessità di vacuum è dovuta all'implementazione del sistema MVCC, non proprietario di PostgreSQL e usato anche in altri RDBMS. Spesso si accusa vacuum di essere uno degli svantaggi di PostgreSQL, senza considerare i vantaggi di MVCC.
Consiglio caldamente la lettura di questo articolo, ben strutturato, che dettaglia la necessità di vacuum nonché come ottimizzare il demone di autovacuum al fine di mantenere buone prestazioni anche in un database di grosse dimensioni.