Sobre "Identificação da transação envolvente"

Agora, li o documento sobre "Transaction ID Wraparound", mas há algo que realmente não entendo, o documento é o seguinte URL http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # VACUUM-FOR-WRAPAROUND

23.1.4 Impedindo falhas abrangentes de ID de transação

A semântica de transações MVCC do PostgreSQL depende da capacidade de comparar números de ID de transação (XID): uma versão de linha com um XID de inserção maior que o XID da transação atual é "no futuro" e não deve estar visível para a transação atual. Porém, como os IDs de transação têm tamanho limitado (32 bits), um cluster que é executado por um longo período de tempo (mais de 4 bilhões de transações) sofreria uma ampla abrangência de IDs de transação: o contador XID fica em torno de zero e, de repente, as transações que estavam no passado parece estar no futuro - o que significa que sua produção se torna invisível. Em suma, perda de dados catastrófica. (Na verdade, os dados ainda estão lá, mas esse é um conforto frio, se você não conseguir entender.) Para evitar isso, é necessário aspirar todas as tabelas em todos os bancos de dados pelo menos uma vez a cada dois bilhões de transações.

Não entendo as declarações "sofreriam uma identificação abrangente da transação: o contador XID se aproxima de zero e, de repente, as transações que ocorreram no passado parecem estar no futuro - o que significa que sua saída se torna invisível"

Alguém pode explicar isso? Por que, depois que o banco de dados sofre um ID de transação abrangente, as transações que estavam no passado parecem ocorrer no futuro? Em resumo, eu quero saber se o PostgreSQL estará na situação "perda de dados" após a identificação da transação envolver-se pelo autovacuum.

Para os meus pontos de vista pessoais, podemos obter o ID da transação atual usando a função txid_current (), cuja saída é de 64 bits e não será executada em ciclo. pela função txid_current (). Exceto que você usará o ID de transação de redefinição de pg_resetxlog reset após desligar o PostgreSQL Server. Estou certo ? obrigado

Por que, depois que o banco de dados sofre um ID de transação abrangente, as transações que estavam no passado parecem ocorrer no futuro?

Eles não. O texto citado apenas explica por que o postgres precisa usar a aritmática do módulo 2 ³¹ (o que significa que as transações podem ser contornadas desde que as transações antigas sejam 'congeladas' cedo o suficiente):

XIDs normais são comparados usando aritmética módulo-2 ^ 31. Isso significa que, para cada XID normal, existem dois bilhões de XIDs "mais antigos" e dois bilhões "mais novos"

para ser específico:

versões de linha antigas devem ser reatribuídas ao XID FrozenXID algum dia antes de atingirem a marca de dois bilhões de transações

ou envolver o XID faria com que as coisas quebrassem. Para evitar isso, o postgres começará a emitir avisos e, eventualmente, será encerrado e se recusará a iniciar novas transações, se necessário:

Se, por algum motivo, o autovacuum falhar na limpeza de XIDs antigos de uma tabela, o sistema começará a emitir mensagens de aviso assim quando os XIDs mais antigos do banco de dados atingirem dez milhões de transações a partir do ponto envolvente:

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

(Um VACUUM manual deve corrigir o problema, conforme sugerido pela dica; mas observe que o VACUUM deve ser executado por um superusuário, caso contrário, ele falhará ao processar os catálogos do sistema e, portanto, não poderá avançar o arquivo de dados congelados do banco de dados.) Se esses avisos são ignorados, o sistema será desligado e se recusará a iniciar novas transações assim que restarem menos de 1 milhão de transações até que envolvam

Em outras palavras, "transações que no passado parecem ocorrer no futuro" e "perda de dados" são inteiramente teóricas e não serão causadas por uma identificação de transação abrangente na prática.

O bloco que você colou parece responder à pergunta. Tudo depende da lógica usada para ocultar transações 'futuras'.

O contador de ID da transação (XID) é limitado a 32 bits e, se algum dia atingir o próximo número, em vez de substituir a transação máxima antiga, ele começará do zero.

Bem, agora é zero, então o PostgreSQL está ocultando todas as transações> 0 dele. Portanto, embora a Transação # 2.147.483.633 tenha acontecido há 20 segundos, o PostgreSQL acha que isso não acontecerá em outras 2.147.483.633 transações.