Re: Initdb panic: invalid record offset at 0/0 creating template1]

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: DANTE ALEXANDRA <ALEXANDRA(dot)DANTE(at)BULL(dot)NET>
Cc: pgsql-general(at)postgresql(dot)org, Agnes Bocchino <agnes(dot)bocchino(at)BULL(dot)NET>
Subject: Re: Initdb panic: invalid record offset at 0/0 creating template1]
Date: 2006-01-20 16:29:55
Message-ID: 18534.1137774595@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

DANTE ALEXANDRA <ALEXANDRA(dot)DANTE(at)BULL(dot)NET> writes:
> We have generated a new rpm as we haven't found a 8.1.0 rpm for IA-64 on
> Red Hat Enterprise Linux 4 on the PostGreSQL web site. We have compiled
> PostGreSQL v8.1.0 and generated the rpm with the intel compiler "icc".
> In the spec file, we have used these options for ./configure :
> ./configure CC=/opt/intel_cc_80/bin/icc CFLAGS="-no-gcc -O2 -w
> -ansi_alias -D__ICC".

Do you know that this compiler generates trustworthy code with those
options? The contents of the pg_control file are clearly good according
to the dump from pg_controldata, and yet we have

> LOG: invalid primary checkpoint link in control file
> PANIC: invalid record offset at 0/0

The easiest explanation I can see for this is that the compiler has
gotten the XRecOffIsValid test at the top of ReadCheckpointRecord
(in src/backend/access/transam/xlog.c, line 4854 as of 8.1.2) backwards.
The first time through, with the perfectly valid primary checkpoint
location (0/20) it mistakenly decides the value is not valid and prints
the LOG message. This leads to a second call with the invalid prior
checkpoint location (0/0), when it mistakenly falls through and calls
ReadRecord, which properly PANICs. Given that ReadRecord is using the
exact same macro to decide the offset is invalid (line 2668), it's hard
to conclude anything except a compiler bug.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephan Vollmer 2006-01-20 16:49:53 Re: Creation of tsearch2 index is very slow
Previous Message Csaba Nagy 2006-01-20 16:18:47 Re: autovacuum and temporary tables