Venho desenvolvendo diversos projetos que integram o Postgres (8.3, 8.4) como solução de SGBD, solução que sempre atendeu as expectativas dos nossos projetos, de todos os pontos de vistas esperados de um SGBD.

Capacidades do pg_dump:

• Tamanho máximo de um banco: Ilimitado
• Tamanho máximo de uma tabela: 64TB
• Tamanho máximo de um registro: Ilimitado
• Tamanho máximo de um campo: 1GB
• Máximo de linhas numa tabela: Ilimitado
• Máximo de colunas numa tabela: 1600
• Máximo de índices numa tabela: Ilimitado

Venho relatar um problema no pg_dump. Como podem ver neste trecho retirado da documentação do Postgres, o tamanho máximo de um campo é de 1GB, em testes o banco de dados realmente suportou! Porém se você tiver um campo acima de 300MB, muito provavelmente não conseguirá fazer o backup desta tabela do seu banco de dados, pois inexplicavelmente o pg_dump aloca uma quantidade muito grande de memória para fazer um backup de um registro deste tamanho.

Segue a mensagem de erro apresentada para o seguinte comando de backup:

# /usr/bin/pg_dump -d -D -F c --disable-triggers --verbose -f "/backup/arquivo.bkp"
pg_dump: saving database definition
pg_dump: SQL command failed
pg_dump: Error message from server: ERRO: invalid memory alloc request size 1353567981
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
pg_dump: *** aborted because of error

Embora o erro não informe a unidade em que está o número considerando que esteja em bytes, isto estaria próximo de 1.3G, que é uma quantidade aceitável de memória em se tratando de servidores. O que posso inferir é que este número não está em bytes, pois o servidor que estava realizando esta rotina estava com 8G de memória RAM mais 8G de swap, que no momento do backup estava com 0% de utilização.

Conclusão

Se quiser fazer backup de seu banco de dados postgres com pg_dump, não tenha registros maiores que 300MB em seu banco.

Outra observação quanto ao uso do pg_dump é o fato dele não dividir o processamento do backup concorrentemente.

Em servidores com 8 processadores a aplicação roda 100% apenas em 1, enquanto os outros 7 ficam ociosos e os discos ociosos também, devido a demora do processamento. A solução neste caso pode ser fazer manualmente o backup de cada tabela separadamente.