There is a special option:
zero_damaged_pages=on that you can use on postgresql.conf, it is documented here.
This option will allow for a pg_dump (or pg_dump_all) that do not stop on critical errors and get as much data back as possible, but you will loose the data that cannot be read.:
(exceprt from documentation, I added the strong.
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