09-04 va acabar amb una pregunta oberta: si SERIALIZABLE no és la resposta per confirmar una comanda, quina ho és? I amb una observació sense explicar: quan la sessió B intentava actualitzar una fila que A ja havia tocat, B es quedava esperant. Aquesta lliçó explica què la retenia, i amb això arriba l'eina que els sistemes de comerç electrònic fan servir de debò perquè dos clients no comprin la mateixa unitat: el bloqueig.

Veuràs els bloquejos de fila implícits que ja estaves provocant sense saber-ho; la família completa de SELECT ... FOR UPDATE i el patró llegir-modificar-escriure segur, que és la solució correcta a l'actualització perduda; SKIP LOCKED per repartir una cua de comandes entre diversos operaris sense trepitjar-se; el bloqueig optimista enfront del pessimista; els bloquejos de taula, què bloqueja un ALTER TABLE i per què havia d'existir CREATE INDEX CONCURRENTLY; i els interbloquejos, amb la seva demostració, el seu missatge real, com els resol el motor i les regles per no provocar-los. Tot reproduïble amb dues terminals psql.

1. Bloquejos de fila implícits
2. La família SELECT ... FOR ...
3. El patró llegir-modificar-escriure segur
4. SKIP LOCKED: la cua de treballs
5. NOWAIT: fallar ràpid
6. Bloqueig optimista enfront de pessimista
7. Bloquejos de taula, ALTER TABLE i CREATE INDEX CONCURRENTLY
8. Interbloquejos
9. Diagnòstic: qui bloqueja qui
10. Els quatre temps d'espera
11. Seqüències, ROLLBACK i els números de factura
12. Errors habituals i consells
13. Exercicis
14. Conclusió del mòdul

No cal demanar un bloqueig: tot UPDATE i tot DELETE bloquegen la fila que toquen fins al final de la transacció. Reprenguem el te matcha (producte 15, stock 40), amb dues terminals:

Quatre lliçons en nou instants:

• t4: llegir no espera. És MVCC (09-02): els lectors no es bloquegen amb els escriptors. B llegeix la versió antiga i continua treballant.
• t5: escriure sí que espera. La terminal de B es queda penjada, sense missatge ni cursor. No és una penjada: és a la cua.
• t7: el bloqueig dura fins al final de la transacció d'A, no fins al final del seu UPDATE. Per això una transacció llarga és una transacció perjudicial (09-01).
• t8: surt 38, no 39. En desbloquejar-se, PostgreSQL va rellegir la fila ja actualitzada i va recalcular stock - 1 sobre 39. És exactament el que va explicar 09-04 sobre per què la forma relativa és segura.

I si A hagués fet ROLLBACK a t6, B hauria continuat igualment, però calculant sobre 40 i deixant l'estoc a 39. En tots dos casos, el resultat és correcte.

De vegades necessites bloquejar una fila abans d'escriure-la, perquè entre la lectura i l'escriptura hi ha una decisió a prendre. Per a això hi ha els bloquejos explícits, quatre i ordenats de més fort a més feble:

I la taula de compatibilitat: ✗ significa que el segon espera el primer.

Aquesta taula, que sembla burocràcia, resol un problema real i molt freqüent: FOR KEY SHARE és el que pren PostgreSQL en comprovar una clau forana. Gràcies al fet que és compatible amb FOR NO KEY UPDATE, inserir una línia de la comanda 21 (que necessita comprovar que la comanda 21 existeix) no espera que una altra sessió actualitzi l'estat d'aquesta comanda. Abans de PostgreSQL 9.3 sí que esperava, i era una font clàssica de bloquejos en cascada.

A la feina diària faràs servir FOR UPDATE en el 95 % dels casos i FOR SHARE en algun control d'integritat. Els altres dos els veuràs als diagnòstics, no els demanaràs tu.

Aquesta és la solució correcta a l'actualització perduda de 09-04, i el patró més important de la lliçó:

I ara les dues sessions alhora, el mateix escenari que perdia una venda a 09-04:

Trenta-vuit. La clau és a t2: el FOR UPDATE de B espera que A acabi, i quan passa, B llegeix 39, no 40. La finestra entre llegir i escriure ha desaparegut, perquè durant tota ella la fila era seva.

Compara-ho amb les altres dues solucions que ja coneixes, perquè totes tres són vàlides i es trien per criteris diferents:

Solució	Quan	Cost
UPDATE ... WHERE id = 15 AND stock >= 1 (09-02)	La lògica cap en una sentència	Cap. És la més ràpida i la primera opció
SELECT ... FOR UPDATE + UPDATE	Cal decidir entre llegir i escriure	Les altres sessions esperen. Predictible
SERIALIZABLE amb reintent (09-04)	L'invariant abasta diverses files	Avortaments i bucle de reintent

Dos avisos sobre FOR UPDATE: no es pot fer servir amb GROUP BY, DISTINCT, UNION ni funcions de finestra, perquè el motor no sabria quines files físiques bloquejar; i bloqueja totes les files que retorna la consulta, així que un SELECT * FROM productes FOR UPDATE sense WHERE bloqueja el catàleg sencer.

Nota de dialecte: SELECT ... FOR UPDATE existeix a PostgreSQL, MySQL/InnoDB i Oracle amb la mateixa sintaxi. SQL Server no la té: fa servir pistes de taula, SELECT ... WITH (UPDLOCK, ROWLOCK). I SQLite l'accepta sintàcticament però no fa res, perquè només admet un escriptor alhora i el problema no se li planteja.

Afegint-hi SKIP LOCKED, la consulta no espera: se salta les files bloquejades i continua amb les següents. És exactament el que cal per repartir feina entre diversos processos.

El cas de BotigaVerda: diversos operaris de magatzem preparen les comandes pagat —avui són la 18 i la 19— i cap no ha d'agafar la mateixa que un altre.

A t1, la consulta d'A retorna la fila 18 | 5 | 2026-01-27; a t2, la de B retorna 19 | 6 | 2026-02-09. Sense SKIP LOCKED, a t2 l'operari 2 s'hauria quedat esperant l'1 per acabar agafant la mateixa comanda que ja estava feta. Amb ell, la consulta es converteix en un repartidor de feina, i és la forma canònica d'implementar una cua de tasques sobre una taula —enviament de correus, generació de factures, sincronització amb el marketplace— sense cap infraestructura addicional.

La tercera opció: ni esperar ni saltar, sinó rendir-se immediatament. SELECT stock FROM productes WHERE id = 15 FOR UPDATE NOWAIT; retorna, si la fila està presa, ERROR: could not obtain lock on row in relation "productes".

Tot l'anterior és bloqueig pessimista: suposes que hi haurà conflicte i reserves la fila per endavant. L'alternativa és suposar que no n'hi haurà i comprovar-ho en escriure.

El bloqueig optimista s'implementa amb una columna de versió que s'incrementa a cada escriptura:

El cicle té tres passos, i entre el primer i el tercer no cal cap transacció oberta — que és tota la gràcia:

I a la sessió que arribi segona, amb la mateixa versio = 0 llegida, la resposta és UPDATE 0.

Zero files afectades: aquest és el senyal. No hi ha error, no hi ha excepció, no hi ha transacció avortada: hi ha un comptador que val 0 i que el teu codi ha de comprovar. Si val 0, algú se't va avançar i cal rellegir, recalcular i tornar-ho a intentar — o mostrar a l'usuari "aquestes dades han canviat mentre editaves".

El risc de l'optimisme: si no comproves el nombre de files afectades, un UPDATE 0 passa completament inadvertit i el canvi es perd en silenci. És el mateix UPDATE N que 05-03 demanava mirar sempre, ara convertit en el mecanisme sencer. Els ORM que implementen aquest patró —Hibernate amb @Version, Django amb select_for_update com a alternativa— llancen una excepció precisament perquè no es pugui ignorar.

A més dels bloquejos de fila, hi ha vuit modes de bloqueig de taula. No cal memoritzar-los; el que cal saber és quin pren cada operació i quin xoca amb quin:

I també es poden demanar a mà, dins d'una transacció — BEGIN; LOCK TABLE productes IN SHARE MODE; … COMMIT; deixa fer un recompte d'inventari coherent sense que ningú escrigui mentrestant.

LOCK TABLE requereix privilegis. Els modes per sobre de ROW EXCLUSIVE exigeixen permisos d'escriptura o de manteniment sobre la taula, no n'hi ha prou amb SELECT. Els privilegis i els rols són 11-03.

I aquí es tanquen dues promeses del curs. La primera és de 05-06: la majoria dels ALTER TABLE prenen ACCESS EXCLUSIVE, el mode que bloqueja tot, incloses les consultes. Per això una migració aparentment innòcua pot tombar un lloc: no pel que trigui a executar-se, sinó perquè primer ha d'esperar que acabin totes les transaccions en curs i, mentre espera, encua al darrere tothom qui arribi. Un ALTER TABLE de 10 ms darrere d'un informe de 40 minuts atura la botiga 40 minuts. D'aquí les dues regles de 05-06: lock_timeout sempre abans d'una migració, i variants que no reescriuen la taula (ADD COLUMN amb DEFAULT és instantani des de PostgreSQL 11; ADD CONSTRAINT ... NOT VALID seguit de VALIDATE CONSTRAINT evita el bloqueig llarg).

La segona és de 08-02: CREATE INDEX normal pren SHARE, que bloqueja totes les escriptures de la taula durant tot el temps que trigui a construir-se — minuts o hores en una taula gran. CREATE INDEX CONCURRENTLY pren només SHARE UPDATE EXCLUSIVE, que no bloqueja ni lectures ni escriptures. El preu és el que va explicar 09-03: recorre la taula dues vegades i espera entre passades que acabin les transaccions antigues, així que triga més, no es pot executar dins d'una transacció i, si falla, deixa un índex invàlid que cal esborrar a mà (es detecta amb indisvalid = false a pg_index). En producció, sempre CONCURRENTLY.

Un interbloqueig (deadlock) passa quan dues transaccions s'esperen mútuament: A espera un recurs que té B, i B espera un que té A. Sense intervenció externa, esperarien per sempre.

La demostració de manual, amb dos productes:

Aquest cicle al graf d'espera és la definició formal de l'interbloqueig, i és el que PostgreSQL busca. El missatge real:

Com el resol el motor. Cada vegada que una transacció porta esperant més de deadlock_timeout (1 segon per omissió), PostgreSQL construeix el graf d'espera i busca cicles. Si en troba un, tria una víctima i avorta la seva transacció amb el codi 40P01. L'altra continua i acaba amb normalitat. No és una configuració que calgui activar: ve posada i funciona sola.

Les quatre regles per no provocar-los:

1. Accedeix sempre als recursos en el mateix ordre. És la regla d'or i resol el 90 % dels casos. Si totes les transaccions que toquen diversos productes els recorren ordenats per id, el cicle és impossible: qui tingui l'1 demanarà el 15, i qui no tingui l'1 l'estarà esperant, sense haver pres res. A la pràctica: ORDER BY id al SELECT ... FOR UPDATE que precedeix les escriptures.
2. Transaccions curtes. Com menys temps se sosté un bloqueig, menor la probabilitat de creuar-se.
3. Res d'interacció humana ni de crides externes a dins. Un usuari pensant amb dues files bloquejades és una fàbrica d'interbloquejos (09-01, 09-03).
4. Toca les files en un sol UPDATE quan puguis. Un UPDATE ... WHERE id IN (1, 15) bloqueja en ordre determinista i no deixa escletxa.

I com a xarxa final: el 40P01 es reintenta igual que el 40001, amb el mateix bucle de retrocés exponencial de 09-04. Per això aquell patró filtrava els dos codis.

Quan alguna cosa "s'ha quedat penjada", aquesta és la consulta que cal tenir desada:

pg_blocking_pids() és la funció clau: retorna directament els processos que estan bloquejant-ne un de donat. Amb el pid culpable (41287), es mira què està fent a pg_stat_activity —molt sovint, res: idle in transaction— i, si cal, es talla:

Per al detall fi existeix pg_locks, que respon a "quin mode exacte està demanant i sobre quin objecte?" — útil sobretot amb els bloquejos de taula de l'apartat 7:

Quatre paràmetres, quatre funcions diferents, i convé no confondre'ls:

Si la taula està ocupada, la sentència falla en dos segons amb ERROR: canceling statement due to lock timeout en lloc d'encuar tota la botiga al seu darrere. Es reintenta més tard i no ha passat res. Sense lock_timeout, aquest ALTER TABLE és una caiguda esperant a passar.

Ja ho has vist tres vegades —a 05-02, a l'exercici 2 de 09-01 i al lot de 09-03— i ara toca el perquè i la conseqüència:

nextval() no és transaccional. Un ROLLBACK no retorna el valor consumit, i per això les seqüències deixen forats.

I és una decisió deliberada, no un descuit. Si nextval respectés les transaccions, hauria de bloquejar la seqüència fins al COMMIT, i totes les sessions que volguessin inserir en aquella taula es posarien en fila índia darrere de la primera: cada INSERT concurrent seria un coll d'ampolla. PostgreSQL canvia unicitat garantida i màxima concurrència per continuïtat, que és el tracte correcte per a una clau subrogada. I d'aquí una conseqüència contundent:

No facis servir mai la clau primària com a número de factura. Una numeració legal de factures ha de ser correlativa i sense forats; una seqüència garanteix que sigui única i creixent, que no és el mateix. Un ROLLBACK, un INSERT fallit o un upsert que acaba en conflicte (05-05) obren un forat, i aquest forat és un problema amb l'Agència Tributària, no un detall estètic.

Les tres maneres d'obtenir una numeració sense forats, amb el seu preu:

La primera és l'habitual, i la seva implementació és exactament el patró de l'apartat 3:

(La taula comptadors_factura és un exemple d'aquesta lliçó i no forma part de l'esquema canònic de BotigaVerda.) Fixa't en el que estàs fent: renunciar deliberadament a la concurrència en un punt concret perquè un requisit legal ho exigeix. Saber quan fer-ho és, en el fons, de què ha anat tot el mòdul.

• Creure que un SELECT normal bloqueja alguna cosa. No bloqueja res, i per això llegir no espera mai. Si necessites que la fila no canviï, ho has de demanar amb FOR UPDATE o FOR SHARE. I llegir sense FOR UPDATE i escriure després és l'actualització perduda de 09-04, ara sense excusa.
• Posar FOR UPDATE en una consulta sense WHERE selectiu. Bloqueges totes les files que retorna; amb el catàleg sencer, has aturat la botiga.
• Oblidar de comprovar el nombre de files afectades amb bloqueig optimista. Un UPDATE 0 és "algú se't va avançar", i si no ho mires el canvi es perd en silenci.
• Llançar un ALTER TABLE en producció sense lock_timeout. Pren ACCESS EXCLUSIVE, espera la transacció més llarga que hi hagi i encua tothom al darrere. I CREATE INDEX sense CONCURRENTLY bloqueja les escriptures durant tota la construcció.
• Tocar diverses files en ordre diferent a cada part del codi. És la recepta de l'interbloqueig. ORDER BY id al SELECT ... FOR UPDATE, sempre.
• Baixar deadlock_timeout "perquè ho detecti abans". No és un límit d'espera: només fa que la comprovació de cicles s'executi més sovint i consumeixi més CPU. I el 40P01 no és un error de programació: és un conflicte temporal que es reintenta, igual que el 40001.
• Fer servir la PK com a número de factura. Les seqüències deixen forats per disseny i la numeració legal no els admet.
• Consell: desa la consulta de pg_blocking_pids. És el primer que s'executa quan alguna cosa es penja, i estalvia mitja hora de conjectures.
• Consell: SKIP LOCKED converteix una taula en una cua de feina. Abans de muntar una infraestructura de missatgeria, comprova si això no et basta.
• Consell: tria pessimista on hi ha contenció real i optimista on hi ha espera humana. Estoc: FOR UPDATE. Formulari d'edició: columna de versió.

Amb dues terminals psql i la base acabada de recarregar.

Resol l'actualització perduda amb bloqueig explícit i compara.

1. Reprodueix l'apartat 3 en dues sessions i comprova que l'estoc final del producte 15 és 38. Anota en quin instant exacte es queda esperant la sessió B i quin valor llegeix en desbloquejar-se.
2. Repeteix-ho canviant el FOR UPDATE de B per FOR UPDATE NOWAIT. Quin missatge surt i en quant de temps?
3. Repeteix-ho amb FOR UPDATE SKIP LOCKED. Quantes files retorna la consulta de B i per què és un resultat perillós en aquest cas concret?
4. Escriu les tres solucions vàlides a aquest problema que ja coneixes (09-02, 09-04 i aquesta lliçó) i digues quina triaries per al carretó de BotigaVerda i per què.

Munta la cua de preparació de comandes del magatzem.

1. Escriu la consulta que pren la comanda pagat més antiga sense trepitjar ningú, i executa-la en dues sessions alhora. Comprova que una agafa la 18 i l'altra la 19.
2. Afegeix-hi una tercera sessió amb la mateixa consulta. Què retorna i per què?
3. Sense SKIP LOCKED, què hauria fet la segona sessió? I què hauria passat en desbloquejar-se, exactament?
4. Dissenya la variant que també serveixi per reintentar comandes que es van quedar a mitges (un operari el procés del qual va morir). Què cal afegir a comandes i per què aquesta columna no forma part de l'esquema canònic?

Provoca un interbloqueig i diagnostica'l.

1. Reprodueix l'apartat 8 amb els productes 1 i 15. Copia el missatge d'error complet i anota quina sessió ha estat la víctima.
2. Mentre les dues estan esperant (abans del segon), executa des d'una tercera sessió la consulta de pg_blocking_pids i descriu el que veus.
3. Reescriu les dues transaccions perquè l'interbloqueig sigui impossible, sense fer servir LOCK TABLE ni canviar el nivell d'aïllament.
4. Si tot i així passés sota càrrega, què hauria de fer l'aplicació? Indica el codi SQLSTATE i el patró exacte.

Solució 1

1. L'estoc final és 38. B es queda esperant al seu propi SELECT ... FOR UPDATE, no a l'UPDATE: aquest és el canvi respecte de l'apartat 1. En desbloquejar-se, després del COMMIT d'A, llegeix 39 — el valor ja actualitzat— i calcula 38 sobre ell. La finestra entre llegir i escriure ha desaparegut.

2. L'error és immediat, en mil·lisegons: ERROR: could not obtain lock on row in relation "productes". I és una resposta perfectament vàlida per a una petició web: val més retornar "torna-ho a provar" a l'instant que deixar l'usuari mirant una roda trenta segons.

3. La consulta de B retorna 0 files, i és perillosíssim aquí. SKIP LOCKED està dissenyat per a "dóna'm qualsevol fila lliure"; però B no vol qualsevol producte: vol aquell. Un resultat buit faria que l'aplicació cregués que el producte 15 no existeix, o —pitjor— que continués sense descomptar res. SKIP LOCKED només té sentit quan les files són intercanviables, com en una cua de feina.

4. Les tres solucions:

Per al carretó de BotigaVerda: la primera, i si el descompte necessita lògica intermèdia (comprovar reserves, aplicar promocions), la tercera. La segona queda descartada perquè obligaria a implementar reintents al camí més calent de la botiga i avortaria justament als pics de trànsit, que és quan pitjor va.

Solució 2

1. La consulta és la de l'apartat 4: SELECT ... WHERE estat = 'pagat' ORDER BY data_comanda FOR UPDATE SKIP LOCKED LIMIT 1. La sessió A agafa la comanda 18 (2026-01-27) i la B, sense esperar, la 19 (2026-02-09).

2. La tercera retorna 0 files, perquè les dues úniques comandes pagat de BotigaVerda estan bloquejades per A i B. És el comportament correcte d'una cua buida: l'operari 3 no espera, veu que no hi ha feina i torna a preguntar més tard.

3. Sense SKIP LOCKED, la segona sessió es quedaria esperant que A acabés. I en desbloquejar-se passaria el pitjor: PostgreSQL rellegeix la fila, reavalua el WHERE i descobreix que la comanda 18 ja no compleix estat = 'pagat' (A la va passar a enviat), així que la descarta i retorna… 0 files. Ni tan sols agafa la 19, perquè el LIMIT 1 ja s'havia resolt. L'operari 2 hauria esperat per no res.

4. Cal marcar les comandes que algú està preparant i des de quan, per poder recuperar les abandonades:

La consulta passa a ser WHERE estat = 'pagat' AND (preparant_des_de IS NULL OR preparant_des_de < now() - INTERVAL '15 minutes'), i el procés escriu preparant_des_de = now() en prendre-la. Així, si un operari mor a mitges, la seva comanda torna a la cua al cap de quinze minuts. No és canònic perquè l'esquema de 01-06 modela una botiga, no una cua de feina: la columna existeix només per a aquest mecanisme i cap altre mòdul no la fa servir.

Solució 3

1. El missatge és el de l'apartat 8, amb deadlock detected i el codi 40P01. La víctima és la sessió que dispara la detecció, és a dir, la que portava esperant més de deadlock_timeout quan es va trobar el cicle — normalment la segona a quedar-se bloquejada (la B del guió). L'altra continua i confirma amb normalitat.

2. Des de la tercera sessió es veuen dues files, cadascuna bloquejada per l'altra: el pid d'A té a bloquejat_per el pid de B, i el de B té el d'A. Aquesta reciprocitat és el cicle del graf d'espera, visible a la sortida d'una consulta. És el diagnòstic més satisfactori del mòdul, i cal ser ràpid: PostgreSQL el resol en aproximadament un segon.

3. N'hi ha prou amb accedir a les files sempre en el mateix ordre, per exemple per id ascendent: les dues sessions executen BEGIN; → UPDATE ... WHERE id = 1; → UPDATE ... WHERE id = 15; → COMMIT;, en aquest ordre. Ara el cicle és impossible: qui aconsegueixi el producte 1 acabarà aconseguint el 15, i qui no l'aconsegueixi estarà esperant sense tenir res bloquejat, així que no pot bloquejar ningú. És la regla d'or de l'apartat 8. La versió general, quan les files es trien en temps d'execució, és ordenar la llista abans de recórrer-la: SELECT ... WHERE id = ANY($1) ORDER BY id FOR UPDATE.

4. Hauria de reintentar la transacció sencera. El codi és 40P01 (deadlock_detected), i el patró és exactament el bucle de 09-04: rollback(), espera amb retrocés exponencial i jitter, fins a cinc intents, sense reintentar cap altre tipus d'error. Per això aquell pseudocodi filtrava '40001' i '40P01': són els dos errors del mòdul que signifiquen "torna-ho a provar", no "ho has fet malament".

Tanques l'última lliçó amb les eines que faltaven:

• Tot UPDATE i DELETE bloqueja la seva fila fins al final de la transacció, i per això la sessió B esperava. Llegir no espera mai; escriure sí. I en desbloquejar-se, PostgreSQL rellegeix i recalcula, que és per què SET stock = stock - 1 donava 38.
• La família SELECT ... FOR UPDATE / FOR NO KEY UPDATE / FOR SHARE / FOR KEY SHARE amb la seva taula de compatibilitat, i el patró llegir-modificar-escriure segur: la solució correcta a l'actualització perduda de 09-04, i la que fan servir de debò les botigues.
• SKIP LOCKED, que converteix una consulta en un repartidor de feina —dos operaris, les comandes 18 i 19, sense trepitjar-se— i NOWAIT per fallar en mil·lisegons en lloc de penjar un usuari.
• Optimista enfront de pessimista: bloquejar per endavant on hi ha contenció real (l'estoc), o comprovar en escriure amb una columna de versió on hi ha espera humana — mirant sempre l'UPDATE 0, perquè allà no hi ha cap error que t'avisi.
• Els bloquejos de taula i els seus vuit modes, amb les dues promeses que es tanquen: la majoria dels ALTER TABLE prenen ACCESS EXCLUSIVE i encuen al darrere tota la base (05-06), i CREATE INDEX bloqueja les escriptures mentre que CREATE INDEX CONCURRENTLY no (08-02). En producció, lock_timeout i CONCURRENTLY, sempre.
• Els interbloquejos: el cicle al graf d'espera, el deadlock detected amb el seu 40P01, la víctima triada pel motor al cap d'un segon, i la regla d'or que els fa impossibles — accedir sempre als recursos en el mateix ordre.
• El diagnòstic: pg_blocking_pids() com a primera consulta davant d'una penjada, pg_locks per al detall, pg_cancel_backend i pg_terminate_backend per tallar, i els quatre temps d'espera amb lock_timeout al capdavant.
• I per què una seqüència no es desfà amb un ROLLBACK: perquè fer-la transaccional convertiria cada INSERT en un coll d'ampolla. D'aquí els forats, i d'aquí la regla: la clau primària no és un número de factura.

I amb això es tanca el mòdul 9. En cinc lliçons has passat de "hi ha una sentència i l'executo" a entendre el sistema sencer: saps que cada sentència solta ja és una transacció i que confirmar una comanda són quatre operacions que han d'anar juntes; coneixes les quatre garanties ACID una a una, amb el WAL que fa que un COMMIT sobrevisqui a un tall de corrent i amb MVCC, que explica per fi les files mortes, el bloat i el VACUUM que van quedar pendents al mòdul 8; manegues el TCL complet, inclosos els SAVEPOINT que rescaten un lot d'una càrrega fallida; saps anomenar les quatre anomalies de concurrència, has vist perdre's una venda de te matcha en dues sessions i saps que PostgreSQL no implementa READ UNCOMMITTED i el seu REPEATABLE READ no permet fantasmes; i saps triar entre una sentència condicional, un FOR UPDATE i un SERIALIZABLE amb reintent sabent què pagues en cada cas.

Ja saps llegir (mòduls 2 a 4 i 7), escriure (mòdul 5), transformar (mòdul 6), optimitzar (mòdul 8) i coordinar (aquest). El que falta no és una capacitat nova: és l'arsenal que fa mantenible tot l'anterior, i que separa una consulta que funciona d'un sistema amb què es pot conviure. Al mòdul 10, Avançat, veuràs les vistes, per donar nom a una consulta complexa i deixar de copiar-la per tot arreu; les CTE amb WITH, que converteixen una subconsulta imbricada de quaranta línies en passos llegibles i permeten escriure consultes recursives per recórrer la jerarquia d'empleats o la cadena de referits de BotigaVerda; les funcions de finestra, amb què es calculen rànquings, mitjanes mòbils i acumulats sense perdre el detall; els procediments emmagatzemats, on acabarà vivint la confirmació de comanda que has construït a 09-03; els triggers, que apliquen automàticament aquelles regles de negoci que 09-02 va deixar fora de l'abast d'un CHECK; i el tipus JSON, per al que no cap en un esquema fix. És la caixa d'eines de qui ja no està aprenent SQL, sinó fent-lo servir.