martedì 23 luglio 2013

Bounces

Ai tempi del glorioso Commodore 64 avevo un giorno, denominato Gladiatori ma il cui vero nome è Bounces veramente bello che mi appassionava moltissimo.
L'idea era dia vere due sfidanti in una camera chiusa, legati alla parete da degli elastici, e che si affrontano a suon di ceffoni e palle tirate addosso.
Perfino la musica mi caricava da matti e lasciavo andare il gioco in demo per godermi gli effetti strabilianti di audio e video che solo il Commodore 64 poteva dare ad un bambimo!


mercoledì 3 luglio 2013

Due feature interessanti di PostgreSQL 9.3

Una delle nuove funzionalita' disponibile con l'imminente usicta di PostgreSQL 9.3 e' il controllo contro la corruzione delle pagine dati.
Nell'era degli hard disk dalle dimensioni enormi, dei dispositivi di memorizzazione portatile e, soprattutto, dei sistemi di reivisione che includono hash crittografici, il controllo contro la corruzione dei dati persistenti e' fondamentale. Non e' un problema di se si rompera' il disco quanto di quando si rompera'.
Simon Riggs, con l'aiuto di altri sviluppatori, ha introdotto un controllo sulle pagine dati mediante un CRC a 16 bit. Sostanzialmente ogni volta che una pagina viene flushata dal memory buffer al disco ne viene calcolato un checksum. Quando la pagina viene ricaricata in memoria il checksum viene controllato.
Cosa succede se il checksum non corrisponde?
Ci sono due alternative: la prima consiste nell'ignorare l'errore e procedere ugualmente, e questa e' ovviamente quella sconsigliata. La seconda prevede che la pagina non sia caricata, ovvero che le tuple non siano accessibili, con conseguente errore di I/O sulla transazione. In sostanza PostgreSQL non e' in grado di prendere alcuna decisione e quindi indica l'errore, lasciando la scelta su cosa fare (accedere i dati forzatamente) al DBA.

Il controllo di coerenza sulla pagina dati deve essere abilitato all'atto di inizializzazione del cluster (ossia initdb) e ovviamente richiedera' un certo ammontare di CPU, che si traduce in un leggero calo di performance (non si puo' avere tutto!). Inoltre sara' disponibile anche un GUC (ossia un parametro di configurazione) per impostare la decisione circa il comportamento in caso di errore.


Un'altra funzione veramente molto interessante e' la presenza di WAL log human readable. La funzione permettera' una analisi dei record contenuti nei WAL e, da una veloce analisi del codice sorgente, il cuore e' rappresentato dal seguente frammento:

static void
XLogDumpDisplayRecord(XLogReaderState *state, XLogRecord *record)
{
...
 printf("xlog record: rmgr: %-11s, record_len: %6u, tot_len: 
         %6u, tx: %10u, lsn: %X/%08X, prev 
         %X/%08X, bkp: %u%u%u%u, desc:",
         desc->rm_name,
         record->xl_len, record->xl_tot_len,
         record->xl_xid,
         (uint32) (state->ReadRecPtr >> 32), 
         (uint32) state->ReadRecPtr,
         (uint32) (record->xl_prev >> 32), 
         (uint32) record->xl_prev,
         !!(XLR_BKP_BLOCK(0) & record->xl_info),
         !!(XLR_BKP_BLOCK(1) & record->xl_info),
         !!(XLR_BKP_BLOCK(2) & record->xl_info),
         !!(XLR_BKP_BLOCK(3) & record->xl_info));

La funzione era gia' stata annunciata al precedente PGDay.IT 2012, e pone le basi per la multi-master replication.

Do you like booleans?

Booleans: you love them or you hate them.
Personally, I hate them.
What is wrong with booleans? Nothing, except that they are often used in the wrong way.
A boolean (that is a condition that is either true or false) can be used only to test a single, autonomous condition. The key word here is "autonomous": the boolean can indicate only one truth at a time.
And developers, of course, know the truth!
So you can end up with some code like the following:

void foo( boolean conditionA, boolean conditionB ){

  if ( conditionA ){ doA(); }
  else if ( conditionB ){ doB(); }
  else doPanic();

}


that is working fine until conditionA and conditionB are totally indipendent. That means not only that a value affects the other, but also that there must be no priority between conditionA and conditionB.
To better understand, suppose that there is a new constraint that imposes that whener conditionA is false, conditionB cannot be true too. Therefore the code becomes:


void foo( boolean conditionA, boolean conditionB ){
  if ( ! conditionA )
    conditionB = false;

  if ( conditionA ){ doA(); }
  else if ( conditionB ){ doB(); }
  else doPanic();

}

Due to the above constraint, there is now a less number of cases:
  • case 1: conditionA = true and conditionB = true;
  • case 2: conditionA = false and conditionB = false;
  • case 3: conditionA = true and conditionB = false.

So there are now three possible cases out of four using two booleans.
Sooner or later, you will miss some check against the possible values and your code, by the way, will result difficult to read. Consider someone who wants to use your API and that has access only to the prototype of the code:

void foo( boolean conditionA, boolean conditionB )

You have to clearly mantain the documentation explaining that the case {false, true} cannot be applied.
So what is the solution?
Instead of having to deal with not-so-boolean booleans, consider using other way of representing a finite, well know, set of possibilities, like enumerations or "old-style" hex variables. They will make your code cleaner and easier to read, and will scale once you have to introduce new constraints.

lunedì 1 luglio 2013

God as a programmer...

Senza intenzione alcuna di essere blasfemo, ecco la parte che mi piace di piu' di questa pagina divertente su come sarebbe Dio se fosse un programmatore:


Why does God allow evil to happen?
God thought He eliminated evil in one of the earlier versions.

How come the Age of Miracles Ended?
That was the development phase of the project; now we are in the maintenance phase.

Does God control everything that happens in my life?
He could if he used the debugger, but it's tedious to step through all those variables.
Where will I go after I die?
Onto a DAT tape and into off-line storage.

Will I be reincarnated?
Not unless there is a special need to restore you to on-line accessibility. And searching those .tar files is a major hassle, so if there is a request for you, God will probably just say that the tape has been lost

Una storia su PostgreSQL...

Non ho seguito nel dettaglio l'affare PostgreSQL-Salesforce, ma ho notato che c'e' stato un po' di confusione circa un post di Bruce Momjian a riguardo. In breve la storia è questa: Salesforce ha annunciato l'anno scorso di voler assumere un certo numero di persone per un grosso progetto PostgreSQL, probabilmente una migrazione; pochi giorni fa invece la notizia che Salesforce ha firmato un programma di nove anni con Oracle. E la cosa e' ben visibile sul sito web di Salesforce.
Nessuno di noi "mortali" sapra' mai cosa e' successo e quali erano o sono le intenzioni di Salesforce, ma ritengo che si sia trattato di un gioco al ribasso: il fatto di aver avviato un migrazione (o meglio, aver annunciato al mondo di volerlo fare) a PostgreSQL, il "concorrente" Oracle lato Open Source, ha dato a Salesforce un grosso potere contrattuale.

E' una cosa preoccupante per PostgreSQL? 
Secondo me no, ma e' evidente che sarebbe stato meglio avere una simile partnership che averla persa per Oracle.

E' una cosa che si puo' evitare in futuro? 
No, e secondo me non si deve nemmeno cercare di evitarla. Questa è una caratteristica intrinseca nel software Open Source, in particolare quello sotto licenza BSD. Non si puo' obbligare nessuno a scegliere una soluzione Open Source, l'unica cosa che si puo' fare è valutare se esista una soluzione Open Source appropriata.

Il thread sulla mailing list -announce.