Incidentally, Tom, you seem to be using a pretty bogus blackhole list that includes blocking static address assignments based on the DNS records. I doubt this achieves much in the way of spam filtering, but it's preventing you from getting my mails. (Perhaps that's a good thing)
--- Begin Message ---This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] SMTP error from remote mailer after MAIL FROM:<[EMAIL PROTECTED]>: host sss.pgh.pa.us [66.207.139.130]: 550 5.7.1 Probable spam from 216.58.44.227 refused - see http://www.five-ten-sg.com/blackhole.php?216.58.44.227 ------ This is a copy of the message, including all the headers. ------ Return-path: <[EMAIL PROTECTED]> Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1D4Nor-0007wA-00; Thu, 24 Feb 2005 13:34:37 -0500 Sender: [EMAIL PROTECTED] To: Tom Lane <[EMAIL PROTECTED]> Cc: Greg Stark <[EMAIL PROTECTED]>, pgsql-hackers@postgresql.org Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> From: Greg Stark <[EMAIL PROTECTED]> Organization: The Emacs Conspiracy; member since 1992 Date: 24 Feb 2005 13:34:36 -0500 Message-ID: <[EMAIL PROTECTED]> Lines: 24 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Tom Lane <[EMAIL PROTECTED]> writes: > Greg Stark <[EMAIL PROTECTED]> writes: > > I'm a bit surprised that the write-cache lead to a corrupt database, and not > > merely lost transactions. I had the impression that drives still handled the > > writes in the order received. > > There'd be little point in having a cache if they did, I should think. > I thought the point of the cache was to allow the disk to schedule I/O > in an order that minimizes seek time (ie, such a disk has got its own > elevator queue or similar). If that were the case then SCSI drives that ship with write caching disabled and using tagged command queuing instead would perform poorly. I think the main motivation for write caching on IDE drives is that the IDE protocol forces commands to be issued synchronously. So you can't send a second command until the first command has completed. Without write caching that limits the write bandwidth tremendously. Write caching is being used here as a poor man's tcq. -- greg
--- End Message ---
-- greg
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
