Postgres – všetko, čo si chcel vedieť, ale bál sa spýtať svojho seniora, aby si nevypadal ako jelito 17. MVCC
Tento prehlad je excerpt z tohoto kratkeho clanku a z tohto dlheho clanku.
Rozne RDBMS sa bezpecuju concurrency control rozne, Postgres pouziva MVCC (s SSI). V skratke to vypada tak, ze deletovane/updatovane tuples postgres nemaze, ale oznaci k zmazaniu (dead rows) a vytvori novy tuple s aktualnou informaciou. Bordel sa potom uprace vacuumom. Toto ma jeden velky pozitivny dopad – ready neblokuju writy a writy neblokuju ready. Nevyhodou, alebo vyzvou je potom ale vytvorit mechanizmus, ktory zabezpecuje izolaciu a konzistenciu (visibility tych tuples, ktore maju byt vidiet, aby sa zamedzilo dirty readom a fantomovemu citaniu atd…)
Mechanizmus, ktory to zabezbecuje, je cez transakcie. Kazda transakcia ma svoj txid, a svoj managment transakcii (sekvencne pridelovanie, subory v pg_xact atd…) a id trandakcie je sekvencne cislo, pre ktore plati “txid < nevidim do buducnosti”. V headeru tuple su 4 identifikatory viazuce sa k transakcii:
- t_xmin – cislo transakcie, ktora previedla INSERT
- t_xmax – id transakcie, ktora previedla UPDATE, alebo DELETE
- t_cid – kolko komandov v transakcii predchadzalo commitu (nerozumiem)
- t_ctid – ukazovatel na sameho seba (nedoslo k UPDATE/DELETE), alebo na dalsi tuple, ktora nesie info o platnej informacii
Na zaklade tychto a aj inych info sa rozhoduje o visibility tuple ramci DDL operacii.
Problemom txid je, ze je to 2^32 integer a teda postpom casu dojde k vycerpaniu tejto sekvencie (je to nieco ako kruhovy buffer) a dochadza k tzv. transaction wraparound problem. Postgres to riesi VACUUM FREEZE sposobom.