Re: bad posix_fadvise support causes initdb to exit ungracefully

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bad posix_fadvise support causes initdb to exit ungracefully
Date: 2011-06-15 16:52:39
Message-ID: BANLkTikQ6eU7r+_H5DG2_9LchDipB16UUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15 June 2011 17:12, Merlin Moncure <mmoncure(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2011-06-15 16:53:24 Re: procpid?
Previous Message Tom Lane 2011-06-15 16:52:30 Re: pg_upgrade using appname to lock out other users