initdb failure on RH 5.10

From: BRUSSER Michael <Michael(dot)BRUSSER(at)3ds(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: initdb failure on RH 5.10
Date: 2014-10-18 18:21:22
Message-ID: B09192DCAA24E1439E57F73035042CB8A6F3A6@AG-DCC-MBX11.dsone.3ds.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

One of our sites ran into a problem with database installation:

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

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

This is Postgres 8.4.4, the installation piece has been stable and always worked, but this time they have a new Red Hat 5.10 server

# uname -a
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

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.10 (Tikanga)

I am not sure if this is helpful, but just in case:
# ldd euc_jis_2004_and_shift_jis_2004.so
linux-vdso.so.1 => (0x00007fff259fd000)
libc.so.6 => /lib64/libc.so.6 (0x00002b3d5a756000)
/lib64/ld-linux-x86-64.so.2 (0x0000003848400000)

And these libs are softlinks:
/lib64/libc.so.6 -> libc-2.5.so
/lib64/ld-linux-x86-64.so.2 -> ld-2.5.so

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?

Thank you,
Michael.

This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email and all attachments,

(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.

For other languages, go to http://www.3ds.com/terms/email-disclaimer

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-10-18 18:30:53 Re: (auto-)analyze causing bloat/load
Previous Message Bruce Momjian 2014-10-18 18:20:45 Re: get_actual_variable_range vs idx_scan/idx_tup_fetch