[HACKERS] 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bad posix_fadvise support causes initdb to exit ungracefully
On Wed, Jun 15, 2011 at 11:12 AM, Merlin Moncure mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bad posix_fadvise support causes initdb to exit ungracefully
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bad posix_fadvise support causes initdb to exit ungracefully
On 15 June 2011 17:12, Merlin Moncure mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bad posix_fadvise support causes initdb to exit ungracefully
Merlin Moncure mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bad posix_fadvise support causes initdb to exit ungracefully
2011/6/15 PostgreSQL - Hans-Jürgen Schönig postg...@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 t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
