| Lists: | pgsql-hackers |
|---|
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | posix_fadvise versus old kernels |
| Date: | 2006-06-27 18:22:32 |
| Message-ID: | 26217.1151432552@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
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
| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: posix_fadvise versus old kernels |
| Date: | 2006-06-27 18:41:56 |
| Message-ID: | 200606271841.k5RIfuk27717@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
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(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: posix_fadvise versus old kernels |
| Date: | 2006-06-27 18:51:12 |
| Message-ID: | 26472.1151434272@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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