Ciao, e benvenuto nella settima puntata della cinquantatreesima stagione. Torniamo a una delle quattro promesse delle transazioni, la durabilità, e guardiamo il meccanismo bellissimo con cui Postgres la mantiene. È un'idea così potente che l'abbiamo già incontrata, in un'altra stagione, in un contesto diverso. Oggi capiamo come si scrive l'intenzione prima del fatto.
Partiamo dalla domanda difficile, perché è cruciale. Postgres ti promette che, quando dice è fatto, il tuo dato è al sicuro per sempre, anche se un millesimo di secondo dopo salta la corrente e la macchina si spegne di colpo. Ma come fa? Scrivere un dato sul disco non è istantaneo, e modificare i dati veri, sparsi qua e là, richiede tempo. Se la corrente va via nel bel mezzo di quella scrittura, rischi di trovare i dati a metà, corrotti. Come si fa a promettere è al sicuro quando il salvataggio vero potrebbe non essere ancora finito?
Voglio darti la soluzione, perché è geniale nella sua semplicità. Il trucco è ribaltare l'ordine: prima di cambiare i dati veri, Postgres scrive da qualche altra parte cosa sta per fare. C'è un registro speciale, un diario, in cui annota l'intenzione: sto per fare questa modifica. Quel diario è scritto in modo semplice e ordinato, aggiungendo sempre in fondo, ed è la cosa che viene messa al sicuro sul disco per prima. Solo dopo che l'intenzione è registrata, Postgres può dire è fatto, e andare con calma a modificare i dati veri. Prima scrivi cosa farai, poi lo fai.
Voglio dirti perché questo salva tutto, perché è il punto. Ora immagina che la corrente vada via proprio nel momento peggiore, dopo che l'intenzione è stata registrata ma prima che i dati veri siano stati aggiornati. Quando la macchina riparte, Postgres rilegge il diario, vede le intenzioni che non erano ancora state completate, e le ripete, finendo il lavoro. Nulla è perso. E se la corrente fosse andata via prima ancora di registrare l'intenzione? Allora quella modifica semplicemente non è mai avvenuta, e i dati sono coerenti, com'erano prima. In ogni caso, niente stati a metà. Il diario è la rete di salvataggio.
Voglio darti l'immagine che rende chiara questa idea, perché è concreta. Pensa al giornale di bordo di una nave. Prima di ogni manovra importante, il capitano scrive nel registro cosa sta per fare, con inchiostro indelebile. Se succede un disastro e bisogna ricostruire cos'è accaduto, il registro racconta l'ultima intenzione chiara, e da lì si riparte. Non è un ripensamento scritto dopo: è l'intenzione messa nero su bianco prima di agire, proprio perché possa sopravvivere a qualsiasi cosa vada storta dopo. Postgres tiene esattamente un giornale di bordo dei suoi cambiamenti.
Voglio collegarlo a una vecchia stagione, perché è la stessa idea profonda. Se questa immagine del diario a cui si aggiunge sempre in fondo ti suona familiare, è perché l'abbiamo già incontrata parlando di una piattaforma di flussi di eventi. Anche lì il cuore era un registro ordinato e immutabile su cui si scrive solo aggiungendo in coda. È una delle idee più feconde dell'informatica: invece di modificare le cose sul posto, tieni un elenco ordinato di cosa è successo. Postgres la usa per sopravvivere ai crash; altri la usano per far parlare i sistemi. Stesso seme, frutti diversi.
Voglio darti un beneficio in più, perché è prezioso. Questo diario non serve solo a riprendersi dai guasti. Siccome contiene, in ordine, tutto ciò che è cambiato, lo si può anche spedire a un'altra macchina, che lo rilegge e applica gli stessi cambiamenti, restando una copia fedele e aggiornata della prima. È così che Postgres tiene delle repliche: copie di sicurezza vive, pronte a subentrare se la macchina principale cade. Lo stesso meccanismo che ti salva da un crash ti regala anche la possibilità di non avere mai un solo punto di rottura. Un'idea, due doni.
Voglio trarre la lezione generale, perché è potente. La lezione è che, per essere davvero affidabili, spesso conviene scrivere l'intenzione prima dell'azione. Registrare cosa stai per fare, in modo sicuro e ordinato, prima di farlo, ti dà un modo per riprenderti da qualsiasi interruzione: sai sempre a che punto eri e cosa restava da fare. È il segreto della durabilità di Postgres, ed è una lezione che vale ben oltre i database, ogni volta che qualcosa non deve andare perso, qualunque cosa succeda.
Per oggi ci fermiamo qui. Abbiamo visto come Postgres mantiene la durabilità. Il problema: scrivere i dati veri richiede tempo, e un crash a metà li corromperebbe. La soluzione è ribaltare l'ordine: prima Postgres scrive in un diario speciale l'intenzione di cosa sta per fare, aggiungendo in fondo, e la mette al sicuro; solo dopo dice è fatto e modifica i dati veri. Se la corrente va via, al riavvio rilegge il diario e finisce il lavoro: nessuno stato a metà. Come il giornale di bordo di una nave, scritto prima di agire. È la stessa idea del registro di eventi di una vecchia stagione, e serve anche a tenere repliche vive. La lezione: scrivi l'intenzione prima dell'azione. Nella prossima puntata: il guardiano della verità. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.