Informazioni su "Transaction ID Wraparound"

Ora, ho letto il documento su "Transaction ID Wraparound", ma c'è qualcosa che davvero non capisco, il documento è il seguente URL http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # VUOTO PER L'AVVOLGENTE

23.1.4. Prevenzione di errori avvolgenti dell'ID transazione

La semantica della transazione MVCC di PostgreSQL dipende dalla possibilità di confrontare i numeri ID transazione (XID): una versione di riga con un XID di inserimento maggiore dell'XID della transazione corrente è "in futuro" e non dovrebbe essere visibile alla transazione corrente. Ma poiché gli ID di transazione hanno dimensioni limitate (32 bit), un cluster in esecuzione per un lungo periodo (oltre 4 miliardi di transazioni) subirebbe un avvolgimento dell'ID transazione: il contatore XID si sposta a zero e tutte le improvvise transazioni che si trovavano nel il passato sembra essere nel futuro, il che significa che la loro produzione diventa invisibile. In breve, catastrofica perdita di dati. (In realtà i dati sono ancora lì, ma è un conforto freddo se non riesci a raggiungerlo.) Per evitare ciò, è necessario aspirare ogni tabella in ogni database almeno una volta ogni due miliardi di transazioni.

Non capisco le affermazioni "subirebbero un avvolgimento dell'ID transazione: il contatore XID si sposta a zero e tutte le transazioni improvvise che erano in passato sembrano essere in futuro - il che significa che il loro output diventa invisibile"

Qualcuno può spiegare questo? Perché dopo che il database subisce un wrapping di ID transazione, le transazioni in passato sembrano essere in futuro? In breve, voglio sapere se PostgreSQL si troverà nella situazione di "perdita di dati" dopo l'ID transazione avvolgente da parte di autovacuum。

Per le mie opinioni personali, possiamo ottenere l'ID della transazione corrente utilizzando la funzione txid_current () che produce output a 64 bit e non verrà ciclicamente. Quindi penso che l'ID della transazione di inserimento delle tuple che sappia come xmin non sarà più grande dell'xid che ottiene dalla funzione txid_current (). Tranne che si utilizzerà pg_resetxlog reset reimposta ID transazione dopo aver chiuso il server PostgreSQL. Ho ragione ? Grazie

Perché dopo che il database subisce un wrapping di ID transazione, le transazioni in passato sembrano essere in futuro?

Non lo fanno. Il testo citato spiega solo perché Postgres deve usare l' aritmica modulo 2 ³¹ (il che significa che le transazioni possono essere completate fintanto che le transazioni precedenti sono "congelate" abbastanza presto):

Gli XID normali vengono confrontati usando l'aritmetica modulo-2 ^ 31. Ciò significa che per ogni XID normale, ci sono due miliardi di XID che sono "più vecchi" e due miliardi che sono "più recenti"

essere specifici:

le vecchie versioni di riga devono essere riassegnate XID FrozenXID prima che raggiungano il segno di due miliardi di transazioni

o avvolgere l'XID in giro causerebbe la rottura delle cose. Per evitarlo, Postgres inizierà a emettere avvisi e alla fine si spegnerà e rifiuterà di avviare nuove transattoni, se necessario:

Se per qualche motivo autovacuum non riesce a cancellare i vecchi XID da una tabella, il sistema inizierà a emettere messaggi di avviso come questo quando gli XID più vecchi del database raggiungono dieci milioni di transazioni dal punto avvolgente:

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

(Un VACUUM manuale dovrebbe risolvere il problema, come suggerito dal suggerimento; ma si noti che VACUUM deve essere eseguito da un superutente, altrimenti non sarà in grado di elaborare i cataloghi di sistema e quindi non sarà in grado di far avanzare il datfrozenxid del database.) Se questi avvisi vengono ignorati, il sistema si spegne e si rifiuta di avviare qualsiasi nuova transazione una volta che sono rimaste meno di 1 milione di transazioni fino al termine

In altre parole, "le transazioni che erano nel passato sembrano essere nel futuro" e "la perdita di dati" sono del tutto teoriche e non saranno causate da un ID di transazione in pratica.

Il blocco che hai incollato sembra rispondere alla domanda. Tutto dipende dalla logica utilizzata per nascondere le transazioni "future".

Il contatore dell'ID transazione (XID) è limitato a 32 bit e se raggiunge quel numero successivo, invece di sostituire la vecchia transazione massima, inizia da zero.

Bene, ora è zero, quindi PostgreSQL nasconde tutte le transazioni> 0 da esso. Quindi, anche se la transazione n. 2.147.483.633 è avvenuta 20 secondi fa, PostgreSQL pensa che non accadrà per altre 2.147.483.633 transazioni.