Re: pg_dumpall -> fails SOLVED

Mario Weilguni wrote:
>
> Am Mittwoch, 28. Februar 2001 10:43 schrieb will trillich:
> > so i've got my data recovered (thanks to oliver) and now
> > i wanna back it up with a pg_dumpall...
> >
> > instead, i get 'failed sanity check, type with oid 779927 was no
> > found' in the oddest places...
>
> I'm just guessing, but it is possible that you're using different versions of
> pg_dump and postmaster? I had a similar problem when I had an old 7.0 binary
> lying around in /usr/bin/ when trying to dump a 7.1 database.

no, it was that i'd been iterating through a series of

drop table xyz;
create table xyz ( ... );
drop function pdq ( xyz );
create function pdq ( xyz ) returns .... ;

when it reached the "drop function" it was referenceing an old
instance (oid) of the xyz table. then a new function was created
that referred to the new table (oid). i found six such functions
referring to nonexistent tables.

apparently postgresql does cascading correctly on rules, indexes,
and triggers when deleting tables that they depend on. but a function
argument that's defined in terms of a table -- apparently that slipped
through the cracks!

i.e.
create table eg( id int4 );
create index ed_id_idx on eg ( id );
create function go( eg ) .... ;
drop table eg; -- this also drops the index, but not the function

so, instead, now i

drop function pdq ( xyz );
drop table xyz;
create table xyz ( ... );
create function pdq ( xyz ) returns .... ;

dropping the function first, works like a charm.

--
mailto:will(at)serensoft(dot)com
http://www.dontUthink.com/