Eu sei que há um problema de "gravações interrompidas" (também conhecidas como "gravações parciais") sobre o arquivo de dados PostgreSQL e, para evitá-lo, o mecanismo FPW (gravação de página inteira) é adotado.
Então, também há um tipo de problema de "gravações parciais" no arquivo de segmento WAL? Em caso afirmativo, existe algum mecanismo para evitá-lo? Se não houver prevenção, isso significa que uma transação confirmada seria perdida em "gravações parciais do arquivo de segmento WAL"?
Na verdade, também tenho dúvidas sobre o FPW. Vamos nos basear no Linux normalmente moderno, o checkpoint adota o modo "sync" normalmente, certo? Se assim for, uma escrita 8K só retorna nos sucessos de ambas as escritas de página 4K OS, certo? Em caso afirmativo, como as "escritas parciais" poderiam acontecer? Por favor, corrija meu entendimento.
Desde já, obrigado!
ATUALIZAÇÃO:
jjanes me responde que:
Uma gravação parcial em uma página WAL falharia na soma de verificação quando ela fosse lida novamente e, portanto, seria interpretada como estando logo além do final do WAL. Portanto, nenhum registro parcial seria repetido.
Acho que posso entender isso, embora isso não cause perda de dados? Especialmente as gravações parciais do WAL ocorreram em uma transação confirmada e reinicie para reproduzir, é possível, embora muito raro?
Uma gravação parcial em uma página WAL falharia na soma de verificação quando ela fosse lida novamente e, portanto, seria interpretada como estando logo além do final do WAL. Portanto, nenhum registro parcial seria repetido.
Uma gravação parcial só pode ocorrer como parte de uma falha ou erro grave. Mas esperamos poder nos recuperar desses...
A menos que synchronous_commit esteja desativado, as transações não são relatadas como confirmadas até que o registro WAL tenha sido completamente gravado e sincronizado. Portanto, os dados que foram perdidos seriam dados que nunca foram relatados como confirmados em primeiro lugar. Se você emitir um COMMIT e não receber uma mensagem de sucesso porque o sistema travou primeiro, então você não sabe se os dados estarão lá ou não quando o sistema voltar.
Agora, se o sistema alegou que os dados foram gravados e sincronizados quando não foram, isso pode levar à perda de dados confirmados, mas isso não é específico para gravações interrompidas - isso é apenas corrupção de dados induzida pelo sistema operacional. Se o sistema operacional disser "algo deu errado", o banco de dados precisa ser capaz de se recuperar. Mas se o sistema operacional afirma que tudo deu certo, mesmo que não, então você está apenas perdido. O banco de dados não pode consertar isso e não é esperado que o faça.
O método de soma de verificação não funcionará com os arquivos de dados, porque eles podem ser substituídos. Portanto, uma soma de verificação inválida informará que a página de dados atual está corrompida, mas sem um FPW não há como recuperar o valor antigo não corrompido para recuperá-lo. Como WAL formalmente nunca é sobrescrito, o problema não ocorre lá.