Recentemente atualizei o PostgreSQL 14 para o PostgreSQL 16 usando o método --clone. Ambos os meus diretórios de dados (cluster antigo e novo) estavam no mesmo volume. Depois de alguns dias, comecei a receber o erro abaixo.
53100: não foi possível estender o arquivo "base/160560/t64_168297303" com FileFallocate(): Não há espaço restante no dispositivo
No momento em que ocorrem erros, eu verifiquei o tamanho livre do volume usando (df -hT) e descobri que mais de 30% do espaço está disponível no volume. Em todos os casos, a consulta que dá esse erro é a consulta CREATE TEMP TABLE. Eu também verifiquei os íons livres durante o mesmo tempo (df -i) e descobri que havia o suficiente disponível.
Também removi o diretório de dados antigo, mas isso não resolveu o erro.
Tenho um servidor primário e 1 servidor de réplica em replicação assíncrona usando patroni.
Versão do PostgreSQL: PostgreSQL 16.6 (Ubuntu 16.6-1.pgdg22.04+1) em x86_64-pc-linux-gnu, compilado por gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64 bits
Consegui criar manualmente um arquivo grande de 40 GB usando fallocate com sucesso, o que aumentou o espaço usado no volume para 96%. É um volume EBS anexado ao EC2 que armazena nada além do diretório de dados PG 16, que tem um link simbólico de pg_wal apontando para um volume diferente.
Mantive o tamanho do volume em 96% e esperei por um período em que o erro geralmente ocorre, mas não ocorreu. Uma coisa a mencionar: após remover o antigo diretório de dados PG 14, o erro ocorreu apenas uma vez. Antes, havia muitas ocorrências, mas não contínuas.
Olhando o código-fonte onde esta mensagem é gerada, eu notaria que o texto "Nenhum espaço restante no dispositivo" está sendo fornecido pelo sistema operacional (ou libc), não pelo próprio PostgreSQL.
Suspeito que o que está acontecendo aqui é que seu espaço livre é altamente fragmentado, de modo que, embora exista espaço livre, ele não pode ser alocado em uma única extensão do tamanho escolhido.
Você poderia argumentar que essa mensagem de erro deveria incluir o número de blocos que ele estava tentando alocar, pois essa informação pode ser útil de saber. Você também poderia argumentar que talvez o PostgreSQL devesse capturar esse erro e voltar para o outro método de alocação, pois há alguma possibilidade de o método de fallback funcionar mesmo quando FileFallocate() falhar.