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

From: Noah Misch <noah(at)leadboat(dot)com>
To: "Weiss, Wilfried" <Wilfried(dot)Weiss(at)nsg(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #9472: pg_dumpall fails with "unrecognized node type: 650"
Date: 2014-03-17 21:32:02
Message-ID: 20140317213202.GA3851906@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Mar 10, 2014 at 10:25:39AM +0100, Weiss, Wilfried wrote:
> 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 unloading and recreating the database.
> It seems that are major differences even though it was the same software level.

PostgreSQL stores facts in its control file sufficient to identify all known
variations of the on-disk binary format. Recompiling the same version with a
different compiler rarely requires a dump/reload, because compilers for the
same hardware often share a C language ABI. When that's not so, PostgreSQL
endeavors to emit an message explaining the incompatibility and refuse to
start against the incompatible data files. Failing to detect a
compiler-induced variation in the on-disk format would be a bug.

> Unfortunately this issue is so exotic that probably no one else can take advantage out of my experience.

If this a reproducible problem for a particular compiler, it's worth fixing.

The PostgreSQL buildfarm currently has no active members running AIX or xlc.
If you're in a position to have a machine perform automated PostgreSQL test
runs, that would greatly increase the chance that PostgreSQL will work out of
the box on your configuration. More information:

http://buildfarm.postgresql.org/cgi-bin/register-form.pl

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Vik Fearing 2014-03-17 22:56:22 Re: BUG #9604: Unable to access table remotely
Previous Message Tom Lane 2014-03-17 20:00:07 Re: relcache reference leak on refresh materialized view concurrently