Acerca de "ID de transacción envolvente"

Ahora, leí el documento sobre "Transaction ID Wraparound", pero hay algo que realmente no entiendo, el documento es la siguiente url http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # VACIO PARA ENVOLVENTE

23.1.4. Prevención de fallas envolventes de ID de transacción

La semántica de transacciones MVCC de PostgreSQL depende de poder comparar los números de ID de transacción (XID): una versión de fila con un XID de inserción mayor que el XID de la transacción actual es "en el futuro" y no debería ser visible para la transacción actual. Pero dado que las ID de transacción tienen un tamaño limitado (32 bits), un clúster que se ejecuta durante mucho tiempo (más de 4 mil millones de transacciones) sufriría una envoltura de ID de transacción: el contador XID se ajusta a cero y, de repente, las transacciones que estaban en el el pasado parece estar en el futuro, lo que significa que su producción se vuelve invisible. En resumen, pérdida de datos catastrófica. (En realidad, los datos todavía están allí, pero es un consuelo frío si no puede llegar a ellos). Para evitar esto, es necesario aspirar todas las tablas de cada base de datos al menos una vez cada dos mil millones de transacciones.

No entiendo las declaraciones "sufriría una envoltura de ID de transacción: el contador XID se ajusta a cero, y de repente las transacciones que estaban en el pasado parecen ser en el futuro, lo que significa que su salida se vuelve invisible"

¿Alguien puede explicar esto? ¿Por qué después de que la base de datos sufre un Wraparound de ID de transacción, las transacciones que estaban en el pasado parecen ser en el futuro? En resumen, quiero saber si PostgreSQL se encontrará en la situación de "pérdida de datos" después de que el ID de transacción se complete automáticamente.

Para mis puntos de vista personales, podemos obtener el ID de transacción actual mediante el uso de la función whoes txid_current (), la salida whoes es de 64 bits y no se reciclará. por la función txid_current (). Excepto que usará pg_resetxlog reset reset ID de transacción después de cerrar el servidor PostgreSQL. Estoy en lo cierto? Gracias

¿Por qué después de que la base de datos sufre un Wraparound de ID de transacción, las transacciones que estaban en el pasado parecen ser en el futuro?

Ellos no. El texto citado solo explica por qué Postgres necesita usar el módulo 2 ³¹ aritmático (lo que significa que las transacciones pueden ajustarse siempre que las transacciones antiguas estén 'congeladas' lo suficientemente temprano):

Los XID normales se comparan utilizando la aritmética módulo 2 ^ 31. Esto significa que por cada XID normal, hay dos mil millones de XID que son "más antiguos" y dos mil millones que son "más nuevos".

ser especifico:

las versiones antiguas de la fila deben reasignarse XID FrozenXID en algún momento antes de que alcancen la marca de dos mil millones de transacciones anteriores

o envolver el XID podría hacer que las cosas se rompan. Para evitar eso, los postgres comenzarán a emitir advertencias, y finalmente se cerrarán y se negarán a iniciar nuevas transacciones si es necesario:

Si, por algún motivo, el vacío automático no borra los XID antiguos de una tabla, el sistema comenzará a emitir mensajes de advertencia como este cuando los XID más antiguos de la base de datos alcancen diez millones de transacciones desde el punto envolvente:

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

(Un VACUUM manual debería solucionar el problema, como sugiere la sugerencia; pero tenga en cuenta que el VACUUM debe ser realizado por un superusuario, de lo contrario, no podrá procesar los catálogos del sistema y, por lo tanto, no podrá avanzar el datfrozenxid de la base de datos). Si se ignoran, el sistema se cerrará y se negará a iniciar cualquier transacción nueva una vez que queden menos de 1 millón de transacciones hasta que finalice

En otras palabras, "las transacciones que fueron en el pasado parecen ser en el futuro" y la "pérdida de datos" son completamente teóricas y no serán causadas por la identificación de la transacción en la práctica.

El bloque que pegó parece responder a la pregunta. Todo depende de la lógica que se usa para ocultar las transacciones 'futuras'.

El contador de ID de transacción (XID) está limitado a 32 bits y si alguna vez alcanza el siguiente número, en lugar de reemplazar la transacción máxima anterior, comienza de cero.

Bueno, ahora es cero, por lo que PostgreSQL está ocultando todas las transacciones> 0. Entonces, aunque la Transacción # 2,147,483,633 ocurrió hace 20 segundos, PostgreSQL cree que no sucederá para otras 2,147,483,633 transacciones.