Subtransações no PostgreSQL: quando 64 SAVEPOINTs derrubam o seu banco
Bárbara Leidens
EDB
Entenda a visibilidade MVCC e o overflow de subtransações no PostgreSQL, um problema real que destrói réplicas sem deixar sinais óbvios
O overflow de subtransações é um dos problemas mais sorrateiros que um cluster PostgreSQL pode enfrentar: não aparece em benchmarks, e quando se manifesta em produção, os sintomas (lentidão generalizada, replicação atrasando, etc.) costumam se espalhar por backends e até por réplicas que não têm absolutamente nada a ver com a transação culpada. Para entender o que está acontecendo, é preciso descer alguns níveis e olhar para como o PostgreSQL realmente gerencia transações, subtransações e visibilidade.
Para isso, começaremos revisitando a base das transações no banco (atribuição de XIDs, montagem de snapshots e o papel do PGPROC no controle de concorrência) para então mostrar o que SAVEPOINT, ROLLBACK TO e blocos BEGIN ... EXCEPTION em PL/pgSQL realmente fazem por baixo dos panos e por que cada um deles custa uma subtransação que pode passar despercebida. Com isso, poderemos então destrinchar o tema central: o cache de 64 subxids, o que acontece quando ele transborda e o efeito dominó que um único backend culpado provoca no sistema inteiro, inclusive em standbys. Finalmente, entenderemos como identificar o problema usando pg_stat_activity, wait events e logs e quais padrões de aplicação costumam causar o overflow. No final, além de ser capaz de diagnosticar e prevenir o problema, você também sai com um modelo mental de como o controle de concorrência do PostgreSQL é implementado.
Subtransações no PostgreSQL: quando 64 SAVEPOINTs derrubam o seu banco
Bárbara Leidens
EDB
Entenda a visibilidade MVCC e o overflow de subtransações no PostgreSQL, um problema real que destrói réplicas sem deixar sinais óbvios
O overflow de subtransações é um dos problemas mais sorrateiros que um cluster PostgreSQL pode enfrentar: não aparece em benchmarks, e quando se manifesta em produção, os sintomas (lentidão generalizada, replicação atrasando, etc.) costumam se espalhar por backends e até por réplicas que não têm absolutamente nada a ver com a transação culpada. Para entender o que está acontecendo, é preciso descer alguns níveis e olhar para como o PostgreSQL realmente gerencia transações, subtransações e visibilidade.
Para isso, começaremos revisitando a base das transações no banco (atribuição de XIDs, montagem de snapshots e o papel do PGPROC no controle de concorrência) para então mostrar o que SAVEPOINT, ROLLBACK TO e blocos BEGIN ... EXCEPTION em PL/pgSQL realmente fazem por baixo dos panos e por que cada um deles custa uma subtransação que pode passar despercebida. Com isso, poderemos então destrinchar o tema central: o cache de 64 subxids, o que acontece quando ele transborda e o efeito dominó que um único backend culpado provoca no sistema inteiro, inclusive em standbys. Finalmente, entenderemos como identificar o problema usando pg_stat_activity, wait events e logs e quais padrões de aplicação costumam causar o overflow. No final, além de ser capaz de diagnosticar e prevenir o problema, você também sai com um modelo mental de como o controle de concorrência do PostgreSQL é implementado.