Обсуждение: BUG #5338: PG_DUMP fails due to invalid adnum value

The following bug has been logged online:

Bug reference:      5338
Logged by:          Toni Helenius
Email address:      toni.helenius@syncrontech.com
PostgreSQL version: 8.3.9
Operating system:   Windows 2008 Server Enterprise
Description:        PG_DUMP fails due to invalid adnum value
Details:

I tried to google this but I didn't get much info. What is this all about??

I get the following error while trying to take a dump:
pg_dump: finding the columns and types of table "bsc_day1_001"
pg_dump: finding default expressions of table "bsc_day1_001"
pg_dump: invalid adnum value 25493128 for table "bsc_day1_001"
pg_dump: *** aborted because of error

Using following command:
pg_dump.exe -h localhost -p 5432 -U postgres -F c -v -f "series.backup" -n
\"SERIES\" db

"Toni Helenius" <toni.helenius@syncrontech.com> writes:
> I tried to google this but I didn't get much info. What is this all about??

> I get the following error while trying to take a dump:
> pg_dump: finding the columns and types of table "bsc_day1_001"
> pg_dump: finding default expressions of table "bsc_day1_001"
> pg_dump: invalid adnum value 25493128 for table "bsc_day1_001"
> pg_dump: *** aborted because of error

Looks like you've got some data corruption in the pg_attrdef catalog :-(
It might be interesting to see what you get from
    select * from pg_attrdef where adrelid = 'bsc_day1_001'::regclass;
which is approximately what pg_dump did here, and didn't like what it
saw.

            regards, tom lane

Toni Helenius <Toni.Helenius@syncrontech.com> writes:
> I actually managed to trace this so that I can reproduce the crashing simply with an empty table created as in
attachment.If I delete the table, everything is fine. The table can be empty and pg_dump still crashes. This is really
weird...

Works for me --- I ran that script and could dump the table no problem.

I'm still thinking this is corruption in your copy of pg_attrdef; maybe
its indexes are messed up.  Try reindexing it.

BTW, you forgot to attach the pg_attrdef query output ...

            regards, tom lane

I reindexed everything and vacuumed. The system tables and our tables. It d=
idn't work. I get the following:


pg_dump: finding the columns and types of table "bsc_day1_001"
pg_dump: finding default expressions of table "bsc_day1_001"

Prosessi palautti lopetuskoodin -1073741819 | (lopetuskoodin =3D exit code)

With:
C:\Program Files (x86)\PostgreSQL\8.3\bin\pg_dump.exe -h localhost -p 5432 =
-U postgres -F c -b -v -f "D:\SyncronTech\Asennus\Migraatio\vkotos.backup" =
vkotos

Could this be 64-bit Windows 2008 SP1 issue? Or Xeon CPU? I don't know, sou=
nds bit weird :/

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: 24. helmikuuta 2010 17:55
To: Toni Helenius
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5338: PG_DUMP fails due to invalid adnum value=20

Toni Helenius <Toni.Helenius@syncrontech.com> writes:
> I actually managed to trace this so that I can reproduce the crashing sim=
ply with an empty table created as in attachment. If I delete the table, ev=
erything is fine. The table can be empty and pg_dump still crashes. This is=
 really weird...

Works for me --- I ran that script and could dump the table no problem.

I'm still thinking this is corruption in your copy of pg_attrdef; maybe
its indexes are messed up.  Try reindexing it.

BTW, you forgot to attach the pg_attrdef query output ...

            regards, tom lane

On Thu, Feb 25, 2010 at 1:58 AM, Toni Helenius
<Toni.Helenius@syncrontech.com> wrote:
> I reindexed everything and vacuumed. The system tables and our tables. It didn't work. I get the following:
>
>
> pg_dump: finding the columns and types of table "bsc_day1_001"
> pg_dump: finding default expressions of table "bsc_day1_001"
>
> Prosessi palautti lopetuskoodin -1073741819 | (lopetuskoodin = exit code)
>
> With:
> C:\Program Files (x86)\PostgreSQL\8.3\bin\pg_dump.exe -h localhost -p 5432 -U postgres -F c -b -v -f
"D:\SyncronTech\Asennus\Migraatio\vkotos.backup"vkotos 
>
> Could this be 64-bit Windows 2008 SP1 issue? Or Xeon CPU? I don't know, sounds bit weird :/

It's almost got to be a data corruption issue, but you still haven't
supplied the output of the query Tom suggested in his first response.

...Robert

On Fri, Feb 26, 2010 at 1:49 AM, Toni Helenius
<Toni.Helenius@syncrontech.com> wrote:
> I did supply it? As cvs-attachment. I'll attach it again with txt-extensi=
on. I tried to reproduce this too with Windows XP 32-bit, Windows 2003 64-b=
it. And I couldn't. Of course I didn't find a Windows 2008 64-bit like the =
original system. But like you said this could be a data corruption and not =
a reproducable bug.

Hmm, it didn't come through last time for some reason - this version
did come through OK.  The original complaint was about an adnum of
25493128, but there's certainly nothing like that in your attachment
here - it only goes up to 961 (which is lot of attributes, but far
short of 25493128!).

Your other attachment with the test case you extracted didn't make it
through to the list either, for some reason.  You might want to repost
that so that someone else who has access to Win2008 can try to
reproduce it.

> I don't know if it counts but the DB has few tables (not the ones with pr=
oblems though) with "invalid byte sequence in UTF8". I don't know do these =
cause data corruption over the whole table. I managed to trace these while =
trying to restore a dump from this DB (UTF-8) (from where I could take the =
dump) to a new Postgre 8.4.2 DB (UTF-8) which refused to restore these tabl=
es.

I doubt that's related.

...Robert