O Postgres sempre grava em tabelas sem que os registros de data e hora do sistema de arquivos sejam atualizados por um longo tempo?

Question

Estou executando o Postgres 9.6 e fazendo backup de vez em quando simplesmente parando o cluster e usando rsync no nível do arquivo. Um dia, reconheci que alguns arquivos antigos, já salvos em backup, para tabelas ainda têm o mesmo tamanho de arquivo e timestamp, como a contraparte na fonte, mas rsync tenta fazer backup deles porque o conteúdo desses arquivos não mudou. É importante observar que, em relação aos timestamps na origem, os arquivos não mudaram por dias ou até semanas. rsync está usando somas de verificação e o cálculo de hashes MD5 para os arquivos em questão também revela hashes diferentes. O seguinte é um exemplo:

Backup:

a1171645dc187c498ce05a25b0e5157f  2613.13

-rw------- 12 109 119 1073741824 May 21 04:58 2613.13

Produção:

f02c1c2724714af2c5c08f8b67ab0f11  2613.13

-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13

O mesmo arquivo exato em relação ao tamanho e ao timestamp, mas na verdade é um conteúdo diferente. Depois de usar rsync com somas de verificação, o arquivo no backup ainda tem o mesmo tamanho e registro de data e hora, mas novo conteúdo, porque desta vez o hash calculado é o mesmo que na produção.

O arquivo pertence a pg_largeobject e essa tabela contém muitos dados, daí os sufixos nomeados. A maioria desses arquivos na sequência tem timestamps antigos como o acima, mais do que alguns dias sem qualquer escrita, e não são todos backup e ter o mesmo hash MD5 como no meu backup. Apenas alguns arquivos de vez em quando diferem como o do exemplo.

Dos seguintes arquivos de dados muito antigos, praticamente inalterados por dias / semanas, por exemplo, 2613.13 foi transferido devido a diferentes somas de verificação, enquanto 2613.10 não:

-rw------- 1 postgres postgres 1073741824 Jun  4 04:40 2613
-rw------- 1 postgres postgres 1073741824 Mai 21 04:42 2613.1
-rw------- 1 postgres postgres 1073741824 Mai 21 04:56 2613.10
-rw------- 1 postgres postgres 1073741824 Mai 21 04:57 2613.11
-rw------- 1 postgres postgres 1073741824 Mai 21 04:57 2613.12
-rw------- 1 postgres postgres 1073741824 Mai 21 04:58 2613.13
-rw------- 1 postgres postgres 1073741824 Mai 21 04:59 2613.14
-rw------- 1 postgres postgres 1073741824 Mai 28 04:40 2613.15
-rw------- 1 postgres postgres  686645248 Jun  4 04:42 2613.16
-rw------- 1 postgres postgres 1073741824 Mai 21 04:44 2613.2
-rw------- 1 postgres postgres 1073741824 Mai 21 04:46 2613.3
-rw------- 1 postgres postgres 1073741824 Mai 21 04:47 2613.4
-rw------- 1 postgres postgres 1073741824 Mai 21 04:49 2613.5
-rw------- 1 postgres postgres 1073741824 Mai 21 04:50 2613.6
-rw------- 1 postgres postgres 1073741824 Mai 21 04:52 2613.7
-rw------- 1 postgres postgres 1073741824 Mai 21 04:53 2613.8
-rw------- 1 postgres postgres 1073741824 Jun  4 04:40 2613.9
-rw------- 1 postgres postgres    4407296 Jun  4 04:42 2613_fsm
-rw------- 1 postgres postgres     548864 Jun  4 04:42 2613_vm

Sendo pg_largeobject e porque na verdade excluímos objetos grandes de o banco de dados de vez em quando, a reutilização de arquivos existentes é perfeitamente aceitável Postgres e como esperado. Mas todos os meus testes mostraram que durante as gravações o timestamp desses arquivos é realmente atualizado e não mantido ou redefinido muito no passado. Nosso sistema de arquivos em uso é ext4, então não deveria tem um problema com os timestamps em geral.

E é isso que me faz pensar: se o Postgres não redefine os timestamps para o passado ou congelá-los de alguma forma, por algum motivo, isso soa como corrupção de dados em meus backups.

Então, existe alguma funcionalidade no Postgres, escrevendo dados sem alterações nos timestamps do arquivo no sistema de arquivos?

Devido à falta de resposta, fiz minha pergunta na lista de discussão do Postgres também.

    

Answer 1

Isso pode não ser um recurso do Postgres, mas a opção de montagem 'noatime' do seu sistema de arquivos que é geralmente usada para aumentar o desempenho dos discos.