Re: pg_dumpall -> fails - Mailing list pgsql-general

From will trillich
Subject Re: pg_dumpall -> fails
Date
Msg-id 20010228140155.C5028@mail.serensoft.com
Whole thread Raw
In response to Re: pg_dumpall -> fails  ("Oliver Elphick" <olly@lfix.co.uk>)
Responses Re: pg_dumpall -> fails
List pgsql-general
On Wed, Feb 28, 2001 at 12:52:10PM +0000, Oliver Elphick wrote:
> will trillich wrote:
>   >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...
>
> More than 1 place?

well, it seems to move around. once per 'pg_dumpall' attempt,
but not always in the same spot...

>   >CREATE FUNCTION "get_failed sanity check, type with oid 779927 was not found
>   >disid" (text,text ) RETURNS int4 AS '
>   >    SELECT
>   >        get_disid( get_eduid($1), $2 )
>   >    ;
>   >' LANGUAGE 'SQL';
>   >[snip]
>
> pg_dump is dumping your functions and for each function it looks up
> the argument type by the oid of the type.  For one function there
> is a type whose oid is 779927, but there is no row in pg_type with
> that oid.

turns out you're right again. :)

i'm doing the "build a structure while ramping up the learning
curve" thing, so i create and drop stuff regularly while i get
this humming the way i want it to...

    -- this kind of thing
    drop table XYZ;
    create table XYZ ( ... );
    drop function munge( XYZ );
    create function munge( XYZ ) returns ... as ... ;

now i've moved my 'drop function' to BEFORE/ABOVE the drop table,
and all is well when i iterate to a new instance of sql code.

when i did as you recommended:

> Look in pg_proc for a function that tries to use a type of 779927:
>
>  select proname, proargtypes, prorettype from pg_proc;

i found several functions with the same name, but different arg
types, because each was referring to a table-def that no longer
existed.

which explains the next thing:

> That will be the one that is causing the problem.  (Of course the
> next question is how it got that way.)

so maybe extra hooks need to be added to be sure that procedures
that depend on tables being dropped, are also dropped at the same
time? just like the 'warning: dropping indexes and rules and
triggers based on this here table you're dropping...' thing?

--
It is always hazardous to ask "Why?" in science, but it is often
interesting to do so just the same.
        -- Isaac Asimov, 'The Genetic Code'

will@serensoft.com
http://groups.yahoo.com/group/newbieDoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

pgsql-general by date:

Previous
From: "Vilson farias"
Date:
Subject: memory allocation
Next
From: "Oliver Elphick"
Date:
Subject: Re: pg_dumpall -> fails