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
