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)
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:
tgl@sss.pgh.pa.us
SMTP error from remote mailer after MAIL FROM:<gsstark@mit.edu>:
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: <gsstark@mit.edu>
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: gsstark@mit.edu
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Stark <gsstark@mit.edu>, pgsql-hackers@postgresql.org
Subject: Re: [pgsql-hackers-win32] [HACKERS] win32 performance - fsync question
References: <6BCB9D8A16AC4241919521715F4D8BCE4769A4@algol.sollentuna.se>
<87r7j5svie.fsf@stark.xeocode.com> <26086.1109267767@sss.pgh.pa.us>
In-Reply-To: <26086.1109267767@sss.pgh.pa.us>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 24 Feb 2005 13:34:36 -0500
Message-ID: <87acptst6r.fsf@stark.xeocode.com>
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 <tgl@sss.pgh.pa.us> writes:
> Greg Stark <gsstark@mit.edu> 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
--
greg
