<!DOCTYPE html>
<html><head>
<meta charset="UTF-8">
</head><body><p class="default-style">Sorry for previous messup.</p><p class="default-style">> Hm, I'd like to know more about that corruption. Did you report it when</p><p class="default-style">> it occured?</p><p class="default-style">Thanks Andres for explanations. I didn't reported the corruption when it</p><p class="default-style">occured as it was my fault, not a PG bug, as the main cause was that I was</p><p class="default-style">using network drive, knowingly it's unreliable for DB but management didn't</p><p class="default-style">believe me.</p><p class="default-style">I had these kind of errors:</p><p class="default-style">pg_dump emet_istina -F c -n usr_...</p><p class="default-style">pg_dump: schema with OID 308991 does not exist</p><p class="default-style">\dt+ pg_temp*.*</p><p class="default-style">ERROR:  catalog is missing 1 attribute(s) for relid 5733555</p><p class="default-style">drop schema pg_temp_9;</p><p class="default-style">ERROR:  cache lookup failed for relation 5733715</p><p class="default-style">drop schema pg_temp_6;</p><p class="default-style">ERROR:  cannot drop schema pg_temp_6 because other objects depend on it</p><p class="default-style">DETAIL:  table pg_temp_6.cur_dde000_105577 depends on schema pg_temp_6</p><p class="default-style">HINT:  Use DROP ... CASCADE to drop the dependent objects too.</p><p class="default-style">I had to manualy remove/edit records from pg_class, pg_type, pg_namespace,</p><p class="default-style">pg_depend, pg_shdepend.</p><p class="default-style">I finaly managed to make it works and could dump everything and rebuild the</p><p class="default-style">DB for more security. Server was down for 1 week, and that event gave me</p><p class="default-style">proven arguments to have local storage. That was with 9.6 and I took the</p><p class="default-style">opportunity to upgrade to 10.3 at the same time.</p><p class="default-style">Now it's more clear it's a PG9/10/12 (I didn't tried 11) problem with</p><p class="default-style">vacuum/autovacuum not changing xid on temp tables. So, as long a temp table</p><p class="default-style">exists, it take age and finish by causing a wraparound protection.</p><p class="default-style">Thierry</p></body></html>