Re: [SPAM] Re: [HACKERS] posix_fadvise v22

2009-01-10 Thread Robert Haas
> 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. This seems pretty pointless,

Re: [SPAM] Re: [HACKERS] posix_fadvise v22

2009-01-10 Thread Bruce Momjian
Tom Lane wrote: > Peter Eisentraut 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 sa

Re: [SPAM] Re: [HACKERS] posix_fadvise v22

2009-01-10 Thread Tom Lane
Peter Eisentraut 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 milli

Re: [SPAM] Re: [HACKERS] posix_fadvise v22

2009-01-05 Thread Peter Eisentraut
Gregory Stark wrote: Peter Eisentraut writes: On Friday 02 January 2009 06:49:57 Greg Stark wrote: The guc run-time check is checking for known-buggy versions of glibc using sysconf to check what version of glibc you have. Could you please mention the bug number in the relevant source code

Re: [SPAM] Re: [HACKERS] posix_fadvise v22

2009-01-03 Thread Gregory Stark
Peter Eisentraut writes: > On Friday 02 January 2009 06:49:57 Greg Stark wrote: >> The guc run-time check is checking for known-buggy versions of glibc   >> using sysconf to check what version of glibc you have. > > Could you please mention the bug number in the relevant source code comments? It