Tom Lane wrote:
> 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 ...
I assumed if effective_io_concurrency < 2 that no posix_fadvise() calls
would be made.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
