Thread: pg_dump crash

Hi, I have just received this crash on pg_dump:

PQgetvalue: ERROR! tuple number 0 is out of range 0..-1
Segmentation fault

it is 7.0.2 and about 130MB database which worked for me for more than a
year (it works as my 'local devel version' of a production system).

What can be the cause of this? I have been messing arround with indexes
just before the error. I wanted to drop some unused indexes and improve
some of my selects with multicolumn ones.
I tend to do drop indexes/vacuum analyze/restore indexes every day.
When I started my 'drop index/vacuum/reindex' script: BANG!
I do:

pg_dump -c -s database > schema.sql
grep -i "drop\ *index" schema.sql > ix_drop.sql
grep -i "create\ *unique\ *index" schema.sql > ix_recreate.sql
grep -i "create\ *index" schema.sql >> ix_recreate.sql
psql database < ix_drop.sql
vacuumdb -v -z database
psql database < ix_recreate.sql

in bash script. Despites its primitiveness it worked for a few months
flawlessly (I run it from cron on my production system nightly).

With the vacuum it crashed on a primary index of one
of the tables (the biggest one), but dropping/recreating the index fixed
the problem. Unfortunately it didn't serve the purpose for the
pg_dump...

pg_dump refuses working with any parameters (dumping data/schema,
selected tables, anything :-(


thanks in advance for any hint.

--
Marek Pętlicki <marpet@buy.pl>

=?iso-8859-2?Q?Marek_P=EAtlicki?= <marpet@buy.pl> writes:
> Hi, I have just received this crash on pg_dump:
> PQgetvalue: ERROR! tuple number 0 is out of range 0..-1
> Segmentation fault

IIRC, this is the symptom of a known bug in pg_dump: in some places it
does a SELECT and just blithely assumes that it will get a tuple back.
If there's no matching tuple, kaboom!  You've probably got something
like a function with no owner in your database.

To determine exactly what's going on, run pg_dump with PGOPTIONS=-d2, ie
    export PGOPTIONS="-d2"
    pg_dump ...
and look at the postmaster's log file (you are keeping a log file I trust)
to see what the last few queries are.  This should let you track down
where the missing reference is, and then you can delete the broken
database item.  If you need help interpreting the info, send along
the last few queries...

            regards, tom lane

On Tuesday, February, 2001-02-06 at 19:35:14, Tom Lane wrote:
> =?iso-8859-2?Q?Marek_P=EAtlicki?= <marpet@buy.pl> writes:
> > Hi, I have just received this crash on pg_dump:
> > PQgetvalue: ERROR! tuple number 0 is out of range 0..-1
> > Segmentation fault
>
> IIRC, this is the symptom of a known bug in pg_dump: in some places it
> does a SELECT and just blithely assumes that it will get a tuple back.
> If there's no matching tuple, kaboom!  You've probably got something
> like a function with no owner in your database.

it turned out to be exactly what you suspect (bogus record in pg_proc, I
don't know the exact problem, but the log showed, that the crash happend
on:

SELECT proname from pg_proc where pg_proc.oid = '7397513'::oid

When I dropped the function everything went OK back again :-)

> To determine exactly what's going on, run pg_dump with PGOPTIONS=-d2, ie
>     export PGOPTIONS="-d2"
>     pg_dump ...
> and look at the postmaster's log file (you are keeping a log file I trust)
> to see what the last few queries are.  This should let you track down
> where the missing reference is, and then you can delete the broken
> database item.  If you need help interpreting the info, send along
> the last few queries...

yes, it helped me a lot! Thank you!
The problem was with my debug session with new trigger functions, which
refused to work and I played with them (dropping and correcting). That's
when I must have inserted the bogus function.

Thank you again for your help!

--
Marek Pętlicki <marpet@buy.pl>