Il locking in PostgreSQL è il meccanismo che garantisce la coerenza dei dati in presenza di accessi concorrenti. PostgreSQL offre diversi livelli di lock — da quelli a livello di riga (row-level lock) a quelli a livello di tabella (table-level lock), fino agli advisory lock applicativi — ciascuno con implicazioni specifiche su performance e rischio di deadlock. Scegliere il tipo di lock appropriato è cruciale per bilanciare integrità e throughput nelle applicazioni ad alto carico.

Partiamo dalle basi: definiamo alcuni concetti di base che saranno ripetuti spesso all’interno di questo post, come il concetto di utente, ruolo e permessi.

Se il concetto di ereditarietà permette di creare una relazione tra una o più tabelle, il partizionamento ne consente una suddivisione logica che si adatta meglio alle esigenze di business.

Il concetto di ereditarietà nella programmazione orientata agli oggetti è un qualcosa di piuttosto popolare: permette infatti di creare una relazione di dipendenza e gerarchia tra due entità, denominate -ad esempio- genitore e figlio.

Implementare una coda di lavoro con PostgreSQL

Quante volte, di fronte alla necessità di processare dei job asincroni in background, la risposta automatica che hai sentito è stata “aggiungiamo Redis” o “mettiamo su RabbitMQ”? Molti danno per scontato che una coda di lavoro richieda un message broker dedicato. In realtà, non è così.