Thread: initdb failure on RH 5.10

initdb failure on RH 5.10

From
BRUSSER Michael
Date:
<div class="WordSection1"><p class="MsoNormal">Hi,<p class="MsoNormal"> <p class="MsoNormal">One of our sites ran into
aproblem with database installation:<p class="MsoNormal"> <p class="MsoNormal"><span style="font-family:"Courier
New"">initdbfailed </span><p class="MsoNormal"><span style="font-family:"Courier New"">FATAL: unexpected data beyond
EOFin block 19 of relation base/1/2609 </span><p class="MsoNormal"><span style="font-family:"Courier New"">HINT: This
hasbeen seen to occur with buggy kernels; consider updating your system. </span><p class="MsoNormal"><span
style="font-family:"CourierNew"">STATEMENT: COMMENT ON FUNCTION euc_jis_2004_to_shift_jis_2004</span><p
class="MsoNormal"><spanstyle="font-family:"Courier New"">          (INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER)
</span><pclass="MsoNormal"><span style="font-family:"Courier New"">           IS 'internal conversion function for
EUC_JIS_2004to SHIFT_JIS_2004'; </span><p class="MsoNormal"> <p class="MsoNormal"> <p class="MsoNormal">initdb is
calledlike this:<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Courier New"">    initdb -D
<data-dir>-L <input-dir> -E UTF8 --locale=C </span><p class="MsoNormal"> <p class="MsoNormal">This is
Postgres8.4.4, the installation piece has been stable and always worked, but this time they have a new Red Hat 5.10
server<pclass="MsoNormal"> <p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Courier New""># uname -a
</span><pclass="MsoNormal"><span style="font-size:12.0pt;font-family:"Courier New"">Linux <hostname>
2.6.18-371.el5#1 SMP Thu Sep 5 21:21:44 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux </span><p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"CourierNew""> </span><p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"CourierNew""># cat /etc/redhat-release </span><p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"CourierNew"">Red Hat Enterprise Linux Server release 5.10 (Tikanga) </span><p
class="MsoNormal"><spanstyle="font-size:12.0pt;font-family:"Courier New""> </span><p class="MsoNormal">I am not sure if
thisis helpful, but just in case:<p class="MsoNormal"><span style="font-family:"Courier New""># ldd
euc_jis_2004_and_shift_jis_2004.so</span><p class="MsoNormal"><span style="font-family:"Courier
New"">   linux-vdso.so.1=> (0x00007fff259fd000) </span><p class="MsoNormal"><span style="font-family:"Courier
New"">   libc.so.6=> /lib64/libc.so.6 (0x00002b3d5a756000) </span><p class="MsoNormal"><span
style="font-family:"CourierNew"">   /lib64/ld-linux-x86-64.so.2 (0x0000003848400000) </span><p class="MsoNormal"><span
style="font-family:"CourierNew""> </span><p class="MsoNormal">And these libs are softlinks:<p class="MsoNormal"><span
style="font-family:"CourierNew"">/lib64/libc.so.6 -> libc-2.5.so</span><p class="MsoNormal"><span
style="font-family:"CourierNew"">/lib64/ld-linux-x86-64.so.2 -> ld-2.5.so</span><p class="MsoNormal"><span
style="font-family:"CourierNew""> </span><p class="MsoNormal">The only thought I have at this point is to run it with
strace,but maybe this is a known issue and someone has a better idea?<p class="MsoNormal"> <p class="MsoNormal">Thank
you,<pclass="MsoNormal">Michael.<p class="MsoNormal"> <p class="MsoNormal"> <p class="MsoNormal"> <p
class="MsoNormal"> <pclass="MsoNormal"> <p class="MsoNormal"> </div><p style="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px
35.4pt;COLOR: #9d9d9d; FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif"> This email and any attachments
areintended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or
privileged.<pstyle="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR: #9d9d9d; FONT-STYLE: italic; FONT-FAMILY: Arial,
Helvetica,sans-serif"> If you are not one of the named recipients or have received this email in error, <p
style="FONT-SIZE:9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR: #9d9d9d; FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica,
sans-serif">(i) you should not read, disclose, or copy it,<p style="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR:
#9d9d9d;FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif"> (ii) please notify sender of your receipt by
replyemail and delete this email and all attachments,<p style="FONT-SIZE: 9pt; MARGIN: 0px 0px 0px 35.4pt; COLOR:
#9d9d9d;FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif"> (iii) Dassault Systemes does not accept or
assumeany liability or responsibility for any use of or reliance on this email.<p style="FONT-STYLE: italic; MARGIN:
0px0px 0px 35.4pt; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #9d9d9d; FONT-SIZE: 9pt"><p style="FONT-SIZE: 9pt;
MARGIN:0px 0px 0px 35.4pt; COLOR: #9d9d9d; FONT-STYLE: italic; FONT-FAMILY: Arial, Helvetica, sans-serif"> For other
languages,go to http://www.3ds.com/terms/email-disclaimer  

Re: initdb failure on RH 5.10

From
Tom Lane
Date:
BRUSSER Michael <Michael.BRUSSER@3ds.com> writes:
> initdb failed
> FATAL: unexpected data beyond EOF in block 19 of relation base/1/2609
> HINT: This has been seen to occur with buggy kernels; consider updating your system.
> STATEMENT: COMMENT ON FUNCTION euc_jis_2004_to_shift_jis_2004
>           (INTEGER, INTEGER, CSTRING, INTERNAL, INTEGER)
>            IS 'internal conversion function for EUC_JIS_2004 to SHIFT_JIS_2004';

That's ... surprising.  We've only ever seen that error message in cases
with heavy concurrent updates and wonky underlying storage; initdb is not
where anyone would expect it.

> initdb is called like this:
>     initdb -D <data-dir> -L <input-dir> -E UTF8 --locale=C

It's not exactly customary to use -L in initdb calls.  Is it possible
you're pointing it to an incompatible library directory?  Not that I see
how that would lead to this behavior, but you're definitely dealing with
something pretty weird.

> This is Postgres 8.4.4, the installation piece has been stable and always worked, but this time they have a new Red
Hat5.10 server
 

What in the world are they doing using 8.4.4?  The entire 8.4.x release
series is out of support anyway, but there is little if any excuse not
to be using the last minor release, 8.4.22.

I'd call your attention also to the fact that RHEL 5.10 is obsolete.
5.11 came out last month, and Red Hat are not known for updating back-rev
release series with inessential bug fixes.

If you can still reproduce this with 5.11 and 8.4.22, people might be
interested in looking more closely.  Otherwise, well, you're dealing
with five-year-old software with a very long list of known bugs.
        regards, tom lane