Re: Broken pg_class table

Roger Ging <roger(at)musicreports(dot)com> writes:
> update pg_class set reltriggers =
> (select count(*) from pg_trigger where tgrelid =
> (select oid from pg_class where relname = '$tbl' and relnamespace =
> (select oid from pg_namespace where nspname = '$sch')))
> --should have been a limiting where clause here

I see, so now *all* the rows of pg_class have some nonzero reltriggers
value, and so the backend is looking for nonexistent entries in
pg_triggers ... or it would be, if it could finish opening pg_triggers,
but it can't do that without finding the nonexistent pg_triggers entries
for pg_triggers ... infinite recursion time.

AFAICS your only hope of getting that database back up is to manually
reset the reltriggers fields to zero in the rows for at least the
critical system catalogs (pg_class, pg_attribute, pg_type, pg_proc,
pg_triggers, pg_constraint might be enough). This is doable with a hex
editor, but it seems kinda painful. You might be best off reverting to
your last backup. If you want to try it, I'd suggest looking for string
table names in the pg_class file and zeroing the two-byte reltriggers
field occurring exactly 112 bytes beyond the start of each name (that
appears to be the correct offset in 8.1). Possibly the easiest thing
is to zero *all* these fields, and then reconstruct the ones that should
be nonzero after you can get into the DB again.

FWIW, as of 8.1 there's no longer any need to do anything as risky as
mucking with reltriggers by hand. Use ALTER TABLE ENABLE/DISABLE
TRIGGER instead.

And by the by, you should definitely not still be using 8.1.0.

regards, tom lane