Fwd: failure notice

The email system at guyr-ml1(at)burntmail(dot)com is spamming me with a
message telling me that guyr-ml1(at)burntmail(dot)com thinks my posts are
spam.

...Robert

---------- Forwarded message ----------
From: <MAILER-DAEMON(at)burntmail(dot)com>
Date: Fri, Oct 29, 2010 at 12:45 PM
Subject: failure notice
To: robertmhaas(at)gmail(dot)com

Hi. This is the qmail-send program at burntmail.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<guyr-ml1(at)burntmail(dot)com>:
Sorry - The message you have sent was identified as spam by Spam
Assassin (message bounced)

--- Below this line is a copy of the message.

Return-Path: <robertmhaas(at)gmail(dot)com>
Received: (qmail 29883 invoked from network); 29 Oct 2010 16:45:55 -0000
Received: from unknown (74.52.149.146)
 by burntmail.com with SMTP; 29 Oct 2010 16:45:55 -0000
>From pgsql-performance-owner+M40991(at)postgresql(dot)org Fri Oct 29 11:45:12 2010
Return-path: <pgsql-performance-owner+M40991(at)postgresql(dot)org>
Envelope-to: guyr-ml1(at)burntmail(dot)com
Delivery-date: Fri, 29 Oct 2010 11:45:12 -0500
Received: from [200.46.208.106] (helo=mx1.hub.org)
       by mx01.burntspam.com with esmtp (Exim 4.63)
       (envelope-from <pgsql-performance-owner+M40991(at)postgresql(dot)org>)
       id 1PBs4l-0004Vn-Sf
       for guyr-ml1(at)burntmail(dot)com; Fri, 29 Oct 2010 11:45:12 -0500
Received: from postgresql.org (mail.postgresql.org [200.46.204.86])
       by mx1.hub.org (Postfix) with ESMTP id 995F33269608;
       Fri, 29 Oct 2010 16:44:31 +0000 (UTC)
Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
       by mail.postgresql.org (Postfix) with ESMTP id 97AAD1337B6C
       for <pgsql-performance-postgresql(dot)org(at)mail(dot)postgresql(dot)org>;
Fri, 29 Oct 2010 13:44:15 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
 by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
 with ESMTP id 59612-09
 for <pgsql-performance-postgresql(dot)org(at)mail(dot)postgresql(dot)org>;
 Fri, 29 Oct 2010 16:44:08 +0000 (UTC)
X-BMDA-Edge: IPR=0,DYN=0,SRB=0,SPM=6.9,BTS=1.1,RBL=0,HIS=0,WHT=0,STR=0
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com
[209.85.214.174])
       by mail.postgresql.org (Postfix) with ESMTP id F24EF133616B
       for <pgsql-performance(at)postgresql(dot)org>; Fri, 29 Oct 2010
13:44:07 -0300 (ADT)
Received: by iwn10 with SMTP id 10so3905880iwn.19
       for <pgsql-performance(at)postgresql(dot)org>; Fri, 29 Oct 2010
09:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
       d=gmail.com; s=gamma;
       h=domainkey-signature:mime-version:received:received:in-reply-to
        :references:date:message-id:subject:from:to:cc:content-type
        :content-transfer-encoding;
       bh=nsTf9SMp9latxxCm4tIz7goGfoWLY9cyktdrdmnQ3NA=;
       b=XMNuOdqxryiNGYUTsa5YW9++XX7vCL/slcrHOmeCXILOSEWPjj4hcYi1d3DACRO2uU
        4YVTKrTYlgJ01AjLZRb4iR8Wa/5j6MoTCgpqyyaBelyCMqEyM5m/cS9KgtVoipnLrC/a
        vYTBfIKrSwmzyGE/HXj40uiBmLSajXTBrJHX8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
       d=gmail.com; s=gamma;
       h=mime-version:in-reply-to:references:date:message-id:subject:from:to
        :cc:content-type:content-transfer-encoding;
       b=bE0oL6KD08QtxQvelBRJ6ZqCDLSgoDrKBXWJvaHQ+SDRg2cPIaSUgwX6axKk2VKDsk
        TZKVtCOWQr/sjigfdHQLuIlzjz99yELrltKIH8WWF36QwiLDpeYXLFuUve7lrj7BKNRj
        gGqxFdBSqBaZSf6qrBYh/Wk2LfdmwxQXHbm8I=
MIME-Version: 1.0
Received: by 10.231.154.73 with SMTP id n9mr4219450ibw.10.1288370647220; Fri,
 29 Oct 2010 09:44:07 -0700 (PDT)
Received: by 10.231.33.71 with HTTP; Fri, 29 Oct 2010 09:44:06 -0700 (PDT)
In-Reply-To: <AANLkTi=ttpLEgYHTViATjbtS_dm-B5iRz3vOmaVDrw__(at)mail(dot)gmail(dot)com>
References: <4CC04EA50200002500036C5E(at)gw(dot)wicourts(dot)gov>
       <201010211935(dot)o9LJZTM21744(at)momjian(dot)us>
       <4CC0513E0200002500036C68(at)gw(dot)wicourts(dot)gov>
       <4CC3E8BF(dot)4090409(at)mansionfamily(dot)plus(dot)com>
       <4CC46479(dot)2050206(at)2ndquadrant(dot)com>
       <16724(dot)1287952819(at)sss(dot)pgh(dot)pa(dot)us>
       <4CC9DE0F(dot)50401(at)mansionfamily(dot)plus(dot)com>
       <26348(dot)1288301177(at)sss(dot)pgh(dot)pa(dot)us>
       <AANLkTimFfBZJ5YCn6tbGbQU_G4GdsQhXbtQ2kTEKfCVx(at)mail(dot)gmail(dot)com>
       <AANLkTi=ttpLEgYHTViATjbtS_dm-B5iRz3vOmaVDrw__(at)mail(dot)gmail(dot)com>
Date: Fri, 29 Oct 2010 12:44:06 -0400
Message-ID: <AANLkTinZ3Vy55ULrQvX_m2J7p0=A59B7hbANVXOv1z1P(at)mail(dot)gmail(dot)com>
Subject: Re: [PERFORM] BBU Cache vs. spindles
From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, James Mansion <james(at)mansionfamily(dot)plus(dot)com>,
       Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov>,
       Bruce Momjian <bruce(at)momjian(dot)us>, jd(at)commandprompt(dot)com,
       Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Steve Crawford
<scrawford(at)pinpointresearch(dot)com>,
       pgsql-performance(at)postgresql(dot)org, Ben Chobot <bench(at)silentmedia(dot)com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
 RCVD_IN_DNSWL_NONE=-0.0001
X-Spam-Level:
X-Mailing-List: pgsql-performance
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo(at)postgresql(dot)org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner(at)postgresql(dot)org>
List-Post: <mailto:pgsql-performance(at)postgresql(dot)org>
List-Subscribe: <mailto:majordomo(at)postgresql(dot)org?body=sub%20pgsql-performance>
List-Unsubscribe:
<mailto:majordomo(at)postgresql(dot)org?body=unsub%20pgsql-performance>
Precedence: bulk
Sender: pgsql-performance-owner(at)postgresql(dot)org
X-Relayed-For: (mx1.hub.org) [200.46.208.106]

On Fri, Oct 29, 2010 at 11:56 AM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> 1) The pages you write to must be in the page cache, or your memcpy is
> going to fault them in. =A0With a plain write, you don't need the
> over-written page in the cache.

I seem to remember a time many years ago when I got bitten by this
problem.  The fact that our I/O is in 8K pages means this could be a
pretty severe hit, I think.

> 2) Now, instead of the torn-page problem being FS block/sector sized
> base, you can now actually have a possibly arbitrary amount of the
> block memory written when the kernel writes out the page. =A0you
> *really* need full-page-writes.

Yeah.

> 3) The mmap overhead required for the kernel to setup the mappings is
> less than the repeated syscalls of a simple write().

You'd expect to save something from that; but on the other hand, at
least on 32-bit systems, there's a very limited number of 1GB files
that can be simultaneously mapped into one address space, and it's a
lot smaller than the number of file descriptors that you can have
open.   Rumor has it that cutting down the number of fds that can stay
open simultaneously is pretty bad for performance, so cutting it down
to a number you can count on one hand (maybe one finger) would
probably be bad.  Maybe on 64-bit it would be OK but it seems like an
awful lot of complexity for at most a minor savings (and a pretty bad
anti-savings if point #1 kicks in).

Anyway this is all totally off-topic...

--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--=20
Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company