No PostgreSQL, assim como demais SGBD’s, temos algumas limitações em relação a alguns aspectos do banco de dados e hoje falaremos sobre a limitação de 32TB que temos por tabela.

Conforme documentação, temos uma limitação de 32TB por tabela quando utilizamos o valor default de 8KB por página:

De imediato este é um valor muito grande e podemos imaginar que é praticamente impossível atingi-lo. E de fato, é um valor alto, mas por algumas vezes já identificamos incidentes causados por esta limitação, causando o seguinte erro:

ERROR: cannot extend file “pg_tblspc/” beyond 4294967295 blocks

Entendendo melhor de onde vem esse erro:

Obs.: Caso não deseje conhecer internamente o motivo pelo qual este erro ocorre, pode pular para o próximo tópico.
Este erro ocorre, pois temos uma limitação de 4294967294 blocos (fixado no código fonte do PostgreSQL):

E de onde vem esta limitação?

Resumidamente, o tipo de dados de 32 bits “unit32” só pode chegar à 2^32 que é 4294967296, e conforme print do código o invalid block number seria 2^32-1. Segue validação:

Voltando à primeira imagem, conforme podemos observar o nosso “MaxBlockNumber” é de 0xFFFFFFFE (Hexadecimal), convertendo isso para decimal é 4294967294 e o erro acontece quando atingimos este limite já com o valor do “InvalidBlockNumber” que é de 4294967295 blocos.

Então considerando o valor Default de 8KB por página, temos:
8 x 4294967296 = 34.359.738.352 KB
Que transformado da 32TB por tabela.

Como diz a própria documentação, esta limitação é quando utilizamos o valor padrão de 8KB por página, caso o valor da nossa página fosse de 16KB, por exemplo, poderíamos ter tabelas maiores, porém mais para frente explicaremos o porquê não levamos em consideração aumentar a página para solucionar o problema do cliente.

Como prevenir deste tipo de problema?

Este é um tipo de incidente que temos como evitar. Logicamente não temos como impedir esta limitação, já que o banco sistema foi arquitetado desta forma, mas que a ação de contorno possa ser realizada em uma janela de manutenção com um planejamento prévio e não no meio do expediente impactando o usuário final. Mas como?
Com ações e monitorações proativas em nosso ambiente.

Se sabemos que temos uma limitação de 32TB por objeto, recomenda-se ficar de olho no crescimento de suas tabelas, principalmente nas maiores.
Seguem alguns scripts que pode te ajudar nesta verificação:

1.Utilizando o psql com o comando dt+

2.Utilizando comandos SQL: 

Solução:
Conforme mencionado anteriormente, uma opção de ultrapassar o limite de 32TB por tabela, seria aumentar o tamanho da página, porém, para isso, teríamos que analisar outros fatores como o impacto que traria para o ambiente em aumentar o tamanho da página do nosso SGBD. Outro fator que se tem que levar em consideração é que para aumentar o valor da página, teríamos que criar um novo Cluster que neste momento (geralmente de um incidente) não considero uma boa opção, além de que não teríamos tempo hábil de mapear todos os impactos. Então a opção mais viável e que gera menos impacto é particionando esta tabela e movimentando seus dados.

No PostgreSQL temos dois tipos de particionamento: Declarativo e de Herança. Dependendo da versão do PostgreSQL (versões menores que a 10), somente o particionamento de Herança que estará disponível, além disso, no particionamento Declarativo temos algumas limitações com que forçará que você tenha que usar o particionamento de Herança. Para sanar mais dúvidas sobre particionamento, recomendamos olhar a documentação oficial.
Conclusão:

Monitorar o seu ambiente proativamente faz com que evitemos determinadas manutenções urgentes durante o horário de expediente impactando o usuário final. Esses tipos de erros ocorrem em ambientes muito grande e geralmente muito transacional, fazendo com que qualquer incidente tenha um grande impacto.
Ter controle do seu ambiente e com o monitoramento em dia, faz com que fique cada vez mais disponível e quando houver a necessidade de grandes manutenções, que sejam realizadas em horários pré-programados.

Texto: Raiane Lins

Referências:
PostgreSQL Limitations: https://www.postgresql.org/docs/12/limits.html
Storage page Layout: https://www.postgresql.org/docs/11/storage-page-layout.html
Storage Error: https://insane.rocks/pg11/md_8c_source.html
Block: https://insane.rocks/pg11/block_8h_source.html
Particionamento: https://www.postgresql.org/docs/12/ddl-partitioning.html