FAQ
Due to unfortunate environmental conditions (don't ask) I've been
trying to get postgres 9.0 up and running on a fairly ancient linux --
redhat EL 3 which as kernel 2.4.21. initdb borks on the create
database step with the error message "child process exited with error
code 139". A bit of tracing revealed the exit was happening at the
pg_flush_data which basically wraps posix_fadvise. Disabling fadvise
support in pg_config_manual.h fixed the problem.

Things brings up a couple of questions:
*) Are linuxes this old out of support?
*) Should configure be testing for working posix_fadvise?

merlin

Search Discussions

  • Merlin Moncure at Jun 15, 2011 at 4:20 pm

    On Wed, Jun 15, 2011 at 11:12 AM, Merlin Moncure wrote:
    Due to unfortunate environmental conditions (don't ask) I've been
    trying to get postgres 9.0 up and running on a fairly ancient linux --
    redhat EL 3 which as kernel 2.4.21.   initdb borks on the create
    database step with the error message "child process exited with error
    code 139".  A bit of tracing revealed the exit was happening at the
    pg_flush_data which basically wraps posix_fadvise.   Disabling fadvise
    support in pg_config_manual.h fixed the problem.

    Things brings up a couple of questions:
    *) Are linuxes this old out of support?
    *) Should configure be testing for working posix_fadvise?
    some searching of the archives turned up this:
    http://archives.postgresql.org/pgsql-committers/2010-02/msg00175.php
    which pretty much explains the issue (see subsequent discussion).

    merlin
  • Hans-Jürgen Schönig at Jun 15, 2011 at 4:44 pm
    hello ...

    2.4? we know that some versions of 2.4 cause problems due to broken posix_fadvise. if i remember correctly we built some configure magic into PostgreSQL to check for this bug. what does this check do?

    many thanks,

    hans


    On Jun 15, 2011, at 6:12 PM, Merlin Moncure wrote:

    Due to unfortunate environmental conditions (don't ask) I've been
    trying to get postgres 9.0 up and running on a fairly ancient linux --
    redhat EL 3 which as kernel 2.4.21. initdb borks on the create
    database step with the error message "child process exited with error
    code 139". A bit of tracing revealed the exit was happening at the
    pg_flush_data which basically wraps posix_fadvise. Disabling fadvise
    support in pg_config_manual.h fixed the problem.

    Things brings up a couple of questions:
    *) Are linuxes this old out of support?
    *) Should configure be testing for working posix_fadvise?

    merlin

    --
    Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
    To make changes to your subscription:
    http://www.postgresql.org/mailpref/pgsql-hackers
    --
    Cybertec Schönig & Schönig GmbH
    Gröhrmühlgasse 26
    A-2700 Wiener Neustadt, Austria
    Web: http://www.postgresql-support.de
  • Merlin Moncure at Jun 15, 2011 at 5:25 pm

    2011/6/15 PostgreSQL - Hans-Jürgen Schönig <postgres@cybertec.at>:
    hello ...

    2.4? we know that some versions of 2.4 cause problems due to broken posix_fadvise. if i remember correctly we built some configure magic into PostgreSQL to check for this bug. what does this check do?
    It doesn't check anything beyond looking for stanard defines --
    posix_fadvise is there but fails immediately with ENOSYS despite what
    the lying manpage says.
    On Wed, Jun 15, 2011 at 12:12 PM, Tom Lane wrote:
    Things brings up a couple of questions:
    *) Are linuxes this old out of support?
    RHEL3 is just about dead as far as Red Hat is concerned: only critical
    security bugs will be addressed, and even that is going to stop in a
    year or two. RH would certainly not recommend that you be trying to
    put any new applications on that platform.
    *) Should configure be testing for working posix_fadvise?
    There isn't any reliable way to do that at configure time, I think.
    We could add an AC_TRY_RUN call but it wouldn't be trustworthy; think
    cross-compiles, or running on some other kernel version than where you
    compiled. Unless the problem manifests on some not-quite-so-dead
    platform, I'm not in favor of it.
    fair enough. anyways, at least it's documented if someone else bumps
    into this...

    merlin
  • Peter Geoghegan at Jun 15, 2011 at 4:53 pm

    On 15 June 2011 17:12, Merlin Moncure wrote:
    Due to unfortunate environmental conditions (don't ask) I've been
    trying to get postgres 9.0 up and running on a fairly ancient linux --
    redhat EL 3 which as kernel 2.4.21.   initdb borks on the create
    database step with the error message "child process exited with error
    code 139".  A bit of tracing revealed the exit was happening at the
    pg_flush_data which basically wraps posix_fadvise.   Disabling fadvise
    support in pg_config_manual.h fixed the problem.

    Things brings up a couple of questions:
    *) Are linuxes this old out of support?
    *) Should configure be testing for working posix_fadvise?
    Doesn't it already test for that? Maybe it isn't doing a good enough
    job in this instance, because the function is present but doesn't
    behave as expected. After all, the wrapping code you refer to only
    builds with a call to posix_fadvise() when various macros are defined.
    It isn't exactly uncommon for it to be merely unavailable - on many of
    our supported platforms, setting effective_io_concurrency to anything
    other than 0 causes an error.

    --
    Peter Geoghegan       http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training and Services
  • Tom Lane at Jun 15, 2011 at 5:12 pm

    Merlin Moncure writes:
    Due to unfortunate environmental conditions (don't ask) I've been
    trying to get postgres 9.0 up and running on a fairly ancient linux --
    redhat EL 3 which as kernel 2.4.21. initdb borks on the create
    database step with the error message "child process exited with error
    code 139". A bit of tracing revealed the exit was happening at the
    pg_flush_data which basically wraps posix_fadvise. Disabling fadvise
    support in pg_config_manual.h fixed the problem.
    Things brings up a couple of questions:
    *) Are linuxes this old out of support?
    RHEL3 is just about dead as far as Red Hat is concerned: only critical
    security bugs will be addressed, and even that is going to stop in a
    year or two. RH would certainly not recommend that you be trying to
    put any new applications on that platform.
    *) Should configure be testing for working posix_fadvise?
    There isn't any reliable way to do that at configure time, I think.
    We could add an AC_TRY_RUN call but it wouldn't be trustworthy; think
    cross-compiles, or running on some other kernel version than where you
    compiled. Unless the problem manifests on some not-quite-so-dead
    platform, I'm not in favor of it.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 15, '11 at 4:12p
activeJun 15, '11 at 5:25p
posts6
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase