Peter Eisentraut <pete...@gmx.net> writes: > The way I read this is that this was a temporary kernel/libc mismatch in > a development version of Debian 3 years ago that was fixed within 2 > months of being reported and was never released to the general public. > So it would be on the same level as any of a million temporary breakages > in Linux distributions under development.
This is incorrect, as the problem was in fact present on Red Hat and presumably all other distros as well. > Unless there are other reports of this problem, I wouldn't bother > testing or working around this at all. If people are running PostgreSQL > 8.4+ on Debian unstable June 2005 with kernel 2.4, they cannot be helped. While I would like to agree with that position, I can't help noticing lines 2438-2461 of xlog.c, which represent the still-smoking wreckage of our last attempt to do something with posix_fadvise. It's not that old either --- we gave up on it less than three years ago: http://archives.postgresql.org/pgsql-hackers/2006-06/msg01481.php I think at a minimum there should be a manual configuration switch (ie something in pg_config_manual.h) to allow the builder to disable use of posix_fadvise, even if configure thinks it's there. Depending on buildfarm results we may have to do more than that. BTW, I intend to un-disable the xlog change when committing the fadvise patch. In for a penny, in for a pound ... 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
