Peter Eisentraut <peter_e@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