Informacje o „podsumowaniu identyfikatora transakcji”

Teraz czytam dokument o „Podsumowaniu identyfikatora transakcji”, ale jest coś, czego tak naprawdę nie rozumiem, dokument to następujący adres URL http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # VACUUM-FOR-WRAPAROUND

23.1.4. Zapobieganie błędom podsumowania identyfikatora transakcji

Semantyka transakcji MVCC PostgreSQL zależy od możliwości porównania numerów identyfikatorów transakcji (XID): wersja wiersza z wstawionym XID większym niż XID bieżącej transakcji jest „w przyszłości” i nie powinna być widoczna dla bieżącej transakcji. Ale ponieważ identyfikatory transakcji mają ograniczony rozmiar (32 bity), klaster działający przez długi czas (ponad 4 miliardy transakcji) ucierpiałby na zawinięciu identyfikatora transakcji: licznik XID zawija się do zera, a wszystkie nagłe transakcje, które miały miejsce przeszłość wydaje się być w przyszłości - co oznacza, że ​​ich twórczość staje się niewidoczna. Krótko mówiąc, katastrofalna utrata danych. (Właściwie dane nadal tam są, ale to zimny komfort, jeśli nie możesz się do nich dostać.) Aby tego uniknąć, konieczne jest odkurzanie każdej tabeli w każdej bazie danych przynajmniej raz na dwa miliardy transakcji.

Nie rozumiem stwierdzeń, że „ucierpiałoby to na zawijaniu identyfikatora transakcji: licznik XID zawija się do zera, a wszystkie nagłe transakcje, które miały miejsce w przeszłości, wydają się być w przyszłości - co oznacza, że ​​ich wyniki stają się niewidoczne”

Czy ktoś może to wyjaśnić? Dlaczego po tym, jak baza danych cierpi na zawijanie identyfikatora transakcji, transakcje, które były w przeszłości, wydają się być w przyszłości? Krótko mówiąc, chcę wiedzieć, czy PostgreSQL znajdzie się w sytuacji „utraty danych” po zawinięciu identyfikatora transakcji przez autovacuum。

Dla moich osobistych poglądów możemy uzyskać bieżący identyfikator transakcji za pomocą funkcji txid_current (), która generuje 64 bitów i nie będzie cykliczna, więc myślę, że identyfikator transakcji wstawiania krotek, które znają jako xmin, będzie nerwowy większy niż xid, który otrzyma przez funkcję txid_current (). Tyle że użyjesz pg_resetxlog zresetuj identyfikator transakcji po zamknięciu serwera PostgreSQL. Czy mam rację ? Dzięki

Dlaczego po tym, jak baza danych cierpi na zawijanie identyfikatora transakcji, transakcje, które były w przeszłości, wydają się być w przyszłości?

Oni nie. Cytowany tekst wyjaśnia tylko, dlaczego postgres musi używać arytmatyki modulo 2 ³¹ (co oznacza, że ​​transakcje mogą się zawijać, o ile stare transakcje są „zamrożone” wystarczająco wcześnie):

Normalne XID są porównywane przy użyciu arytmetyki modulo-2 ^ 31. Oznacza to, że dla każdego normalnego XID istnieją dwa miliardy XID, które są „starsze” i dwa miliardy, które są „nowsze”

być konkretnym:

stare wersje wierszy muszą zostać ponownie przypisane XID FrozenXID, zanim osiągną znak sprzed dwóch miliardów transakcji

lub owijanie XID może spowodować uszkodzenie. Aby temu zapobiec, postgres zacznie emitować ostrzeżenia, a następnie zamknie się i odmówi uruchomienia nowych transakcji, jeśli to konieczne:

Jeśli z jakiegoś powodu autovacuum nie usunie starych XID z tabeli, system zacznie emitować takie komunikaty ostrzegawcze, gdy najstarsze XID bazy danych osiągną dziesięć milionów transakcji od momentu zawinięcia:

WARNING:  database "mydb" must be vacuumed within 177009986 transactions 
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb". 

(Instrukcja VACUUM powinna rozwiązać problem, jak sugeruje wskazówka; należy jednak pamiętać, że VACUUM musi zostać wykonane przez administratora, inaczej nie przetworzy katalogów systemowych, a tym samym nie będzie w stanie przyspieszyć przesyłania danych do bazy danych.) Jeśli te ostrzeżenia zostaną zignorowane, system wyłączy się i odmówi rozpoczęcia nowych transakcji, gdy pozostanie mniej niż milion transakcji do zakończenia

Innymi słowy „transakcje, które miały miejsce w przeszłości, wydają się być w przyszłości” i „utrata danych” są całkowicie teoretyczne i nie będą w praktyce powodowane przez zawijanie identyfikatorów transakcji.

Wklejony blok wydaje się odpowiadać na pytanie. Wszystko zależy od logiki używanej do ukrywania „przyszłych” transakcji.

Licznik identyfikatora transakcji (XID) jest ograniczony do 32 bitów i jeśli kiedykolwiek osiągnie następną liczbę, zamiast zastępować starą maksymalną transakcję, zaczyna od nowa od zera.

Teraz jest zero, więc PostgreSQL ukrywa przed nim wszystkie transakcje> 0. Więc chociaż transakcja nr 2 147 483 643 miała miejsce 20 sekund temu, PostgreSQL uważa, że ​​nie nastąpi to dla kolejnych 2147483 633 transakcji.