Обсуждение: bad posix_fadvise support causes initdb to exit ungracefully

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

On Wed, Jun 15, 2011 at 11:12 AM, Merlin Moncure <mmoncure@gmail.com> 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

hello ...

2.4? we know that some versions of 2.4 cause problems due to broken posix_fadvise. if i remember correctly we built
someconfigure 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

On 15 June 2011 17:12, Merlin Moncure <mmoncure@gmail.com> 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

Merlin Moncure <mmoncure@gmail.com> 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

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
someconfigure 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 <tgl@sss.pgh.pa.us> 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