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
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 |