Thread: posix_fadvise versus old kernels
I've been digging into why buildfarm member thrush has been dumping core consistently during the regression tests since the posix_fadvise patch went in. I've confirmed that posix_fadvise() itself will SIGSEGV in a standalone test program, and found that this happens only if _FILE_OFFSET_BITS=64 ... which is our default configuration on Linux. Some googling turned up the following http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313219 which basically says that posix_fadvise64 + 2.4 kernel + older glibc = crash. It sounds like the 2.4 kernel hasn't got this call but glibc thought it did, up till about a year ago. While we could possibly come up with a suitable configure test to determine whether posix_fadvise is actually safe to use on a given system, I think we should seriously consider just reverting the patch. As far as I saw, zero evidence was given that it actually does anything measurable. Without a benchmark to prove that it's worth spending more time on, I'm disinclined to trouble over it. regards, tom lane
Tom Lane wrote: > I've been digging into why buildfarm member thrush has been dumping core > consistently during the regression tests since the posix_fadvise patch > went in. I've confirmed that posix_fadvise() itself will SIGSEGV in a > standalone test program, and found that this happens only if > _FILE_OFFSET_BITS=64 ... which is our default configuration on Linux. > > Some googling turned up the following > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313219 > which basically says that posix_fadvise64 + 2.4 kernel + older glibc > = crash. It sounds like the 2.4 kernel hasn't got this call but glibc > thought it did, up till about a year ago. > > While we could possibly come up with a suitable configure test to > determine whether posix_fadvise is actually safe to use on a given > system, I think we should seriously consider just reverting the patch. > As far as I saw, zero evidence was given that it actually does anything > measurable. Without a benchmark to prove that it's worth spending more > time on, I'm disinclined to trouble over it. Agreed. How about if we just #ifdef NOT_USED the code and mention the problem in a comment. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> While we could possibly come up with a suitable configure test to
>> determine whether posix_fadvise is actually safe to use on a given
>> system, I think we should seriously consider just reverting the patch.
>> As far as I saw, zero evidence was given that it actually does anything
>> measurable. Without a benchmark to prove that it's worth spending more
>> time on, I'm disinclined to trouble over it.
> Agreed. How about if we just #ifdef NOT_USED the code and mention the
> problem in a comment.
Works for me; I'll write something and commit it. We can leave the
is-posix_fadvise-declared configure test in place, at least for now ...
regards, tom lane