Não é incomum durante uma restauração de todo o banco de dados, porque é uma operação excepcionalmente grande. Se você vir isso durante a operação normal, considere aumentar sua configuração checkpoint_segmentspermanentemente, exatamente como a mensagem de erro sugere.
Você pode ter o problema de definir um valor checkpoint_segmentsmais alto pouco antes da restauração e abaixá-lo novamente. É isso mesmo que o manual sugere (incluindo uma explicação) :
O aumento temporário da checkpoint_segmentsvariável de configuração também pode acelerar o carregamento de grandes dados. Isso ocorre porque o carregamento de uma grande quantidade de dados no PostgreSQL fará com que os pontos de verificação ocorram com mais frequência do que a frequência normal do ponto de verificação (especificado pela
checkpoint_timeoutvariável de configuração). Sempre que ocorre um ponto de verificação, todas as páginas sujas devem ser lavadas no disco. Ao aumentar
checkpoint_segmentstemporariamente durante o carregamento de dados em massa, o número de pontos de verificação necessários pode ser reduzido.
Resposta relacionada com mais detalhes:
Postgres 9.5
O próximo lançamento tem uma abordagem mais inteligente. Citando as notas da versão beta :
Substitua o parâmetro de configuração checkpoint_segmentspor min_wal_size
e max_wal_size(Heikki Linnakangas)
Isso permite a alocação de um grande número de arquivos WAL sem mantê-los, se não forem necessários. Assim, o padrão para max_wal_size
foi aumentado para 1GB.
Além disso: o número de visualizações é pouco relevante, elas não contêm dados, apenas a "receita", ou seja: a consulta e alguns atributos da visualização. Para a questão em questão, basicamente apenas o tamanho total do arquivo de backup é importante.
