Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 795606322F6 for ; Sat, 10 Jan 2009 14:51:46 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 30047-10 for ; Sat, 10 Jan 2009 14:51:43 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 2FC206322F1 for ; Sat, 10 Jan 2009 14:51:43 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n0AIp526024022; Sat, 10 Jan 2009 13:51:05 -0500 (EST) To: Peter Eisentraut cc: Gregory Stark , pgsql-hackers@postgresql.org, Greg Stark , Robert Haas , ITAGAKI Takahiro Subject: Re: [SPAM] Re: posix_fadvise v22 In-reply-to: <4961C80C.6030307@gmx.net> References: <603c8f070901012011hca2c36flf527a5cd01695205@mail.gmail.com> <262184F8-1206-4E2C-B50F-9FF84E63C1B6@enterprisedb.com> <200901032342.19435.peter_e@gmx.net> <87iqowt3ba.fsf@oxford.xeocode.com> <4961C80C.6030307@gmx.net> Comments: In-reply-to Peter Eisentraut message dated "Mon, 05 Jan 2009 10:42:52 +0200" Date: Sat, 10 Jan 2009 13:51:05 -0500 Message-ID: <24021.1231613465@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/769 X-Sequence-Number: 131413 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 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 ... regards, tom lane