No es raro durante una restauración de base de datos completa porque es una operación excepcionalmente grande. Si ve esto durante el funcionamiento normal, considere aumentar su configuración de forma checkpoint_segmentspermanente, tal como lo indica el mensaje de error.
Es posible que tenga problemas para configurar checkpoint_segmentsmás alto justo antes de la restauración y luego volver a bajarlo. Esto es incluso lo que sugiere el manual (incluida una explicación) :
El aumento temporal de la checkpoint_segmentsvariable de configuración también puede acelerar la carga de datos de gran tamaño. Esto se debe a que cargar una gran cantidad de datos en PostgreSQL hará que los puntos de control ocurran con más frecuencia que la frecuencia de punto de control normal (especificada por la
checkpoint_timeoutvariable de configuración). Siempre que se produce un punto de control, todas las páginas sucias se deben vaciar al disco. Al aumentar
checkpoint_segmentstemporalmente durante las cargas de datos en masa, se puede reducir la cantidad de puntos de control necesarios.
Respuesta relacionada con más detalles:
Postgres 9.5
El próximo lanzamiento nuevo tiene un enfoque más inteligente. Citando las notas de la versión beta :
Reemplace el parámetro de configuración checkpoint_segmentscon min_wal_size
y max_wal_size(Heikki Linnakangas)
Esto permite la asignación de una gran cantidad de archivos WAL sin guardarlos si no son necesarios. Por lo tanto, el valor predeterminado para max_wal_size
se ha aumentado a 1GB.
Aparte: el número de vistas es apenas relevante, esas no contienen ningún dato, solo la "receta", es decir: la consulta y algunos atributos de la vista. Para la pregunta en cuestión, básicamente solo importa el tamaño total del archivo de copia de seguridad.