Hola RIcardo
en primer lugar, ese error deberia estar asociado a una tabla o indice que esta mal, tiene alguna pagina con corrupcion. Por lo tanto, en cuanto puedas trata de recrear la base completa .
otra cosa que te sugiero es tratar de indentificar en que tabla esta el error, de repente podes mandar la salida del pg_dump a un archivo, y cuanto cancele fijarte que tabla estaba procesando en ese momento
Existe un parametro en postgres que le indica que cuando encuentre un error de corrupcion, no corte, sino que de un warning y siga procesando, ese parametro es: zero_damaged_pages. Proba seteandolo en ON a ver si el pg_dump termina. OJO que este parametro ignora la pagina con errores, por lo tanto el pg_dump no va a tener una version completa de la tabla!!! Aqui abajo te pongo la descripcion del parametro
zero_damaged_pages (boolean)
Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. However, it does allow you to get past the error and retrieve rows from any undamaged pages that might be present in the table. It is useful for recovering data if corruption has occurred due to a hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged pages of a table. Zeroed-out pages are not forced to disk so it is recommended to recreate the table or the index before turning this parameter off again. The default setting is off, and it can only be changed by a superuser.