Tom Lane wrote: > 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 ...
I assumed if effective_io_concurrency < 2 that no posix_fadvise() calls would be made. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
