Achilleas writes:
> First try to find which tables those toast relations refer to :
> select 10919630::regclass , 10920100::regclass ;
> Are those critical tables? Can you restore them somehow?
They are our two big tables, containing the bulk of our data (one with
168M rows, the other with 320M rows).
They are constantly being updated, but if I can identify the affected
rows, I can restore a backup on another machine and cherry pick them
from there.
> Also you may consider
> REINDEX TABLE pg_toast.pg_toast_10920100;
> REINDEX TABLE pg_toast.pg_toast_10919630;
> REINDEX TABLE <name of table 10920100>;
> REINDEX TABLE <name of table 10919630>;
>
> also VACUUM the above tables.
Yes, but I'd like to know find out why it happens, because cleaning up
and having the corruption reoccur is not so fun.
> You might want to write a function which iterates over the damaged
> table's rows in order to identify the damaged row(s). And then do some
> good update to create a new version.
Yes - we started by doing a quick pg_dump, but I guess we should switch
to something that can tell us exactly what rows hit the problem.
Anyone has a handy little script lying around?
Thanks for the response!
Adam
--
"Lägg ditt liv i min hand Adam Sjøgren
Sälj din själ till ett band" adsj@xxxxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
