Re: BUG #9472: pg_dumpall fails with "unrecognized node type: 650"

Hi Tom,

sorry for confusing you.
I found the reason for this issue.

Originally I compiled pg 9.2.2 using gcc and everything worked fine.
Then I compiled it again using xlc and restarted the engine without unload=
ing and recreating the database.
It seems that are major differences even though it was the same software l=
evel.

Basically I prefer xlc as it runs better on AIX but there were some moneta=
ry reasons that made me try gcc.

Unfortunately this issue is so exotic that probably no one else can take a=
dvantage out of my experience.

Thank you for turning me into the right direction. It helped a lot.

Regards
Wilfried =20

-----Urspr=FCngliche Nachricht-----
Von: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Gesendet: Freitag, 7. M=E4rz 2014 18:17
An: Weiss, Wilfried
Cc: pgsql-bugs@postgresql.org
Betreff: Re: [BUGS] BUG #9472: pg_dumpall fails with "unrecognized node ty=
pe: 650"

Wilfried.Weiss@nsg.com writes:
> pg_dumpall: query failed: ERROR:  unrecognized node type: 650
> pg_dumpall: query was: SELECT datname, coalesce(rolname, (select rolname=

> from pg_authid where oid=3D(select datdba from pg_database where
> datname=3D'template0'))), pg_encoding_to_char(d.encoding), datcollate,
> datctype, datfrozenxid, datistemplate, datacl, datconnlimit, (SELECT spc=
name
> FROM pg_tablespace t WHERE t.oid =3D d.dattablespace) AS dattablespace F=
ROM
> pg_database d LEFT JOIN pg_authid u ON (datdba =3D u.oid) WHERE datallow=
conn
> ORDER BY 1

That's very bizarre.  The implication of the error message is that
something examining a query parsetree found a Value node where it
wasn't expecting one.  Ordinarily I'd think a parser or planner bug,
but since this is a standard query in pg_dumpall, it's hard to see
how such a bug could have escaped notice.  Another possible theory
is system-catalog corruption, but I don't see how that would explain
this particular symptom.  I wonder if you've got a corrupted postgres
executable.

In any case, since you're running a version that's a year or two
obsolete, updating to 9.2.latest would be a good first step.

> What can I do to be able to unload the data again?

If upgrading doesn't help, I'd try telling pg_dumpall to connect
to a different database initially (see -d option).  If it is some
bizarre species of catalog corruption, it probably is affecting
the postgres database only, so this might dodge the issue.

Failing that, try pg_dump'ing individual databases.

=09=09=09regards, tom lane

http://nsg.com/disclaimer