Thanks, Tom for keeping on this. I was on vacation last week. Will try
the latest ASAP.
On Mon, 2005-08-22 at 20:20 -0400, Tom Lane wrote:
> I wrote:
> > I've been sniffing around that patch and not really finding any smoking
> > gun about why it would make things slower when you're not using O_DIRECT.
>
> While rewriting the patch to fit more naturally into xlog.c, I found a
> bug that might possibly be related to your performance issue. The
> if-test in this fragment is wrong:
>
> /*
> * If we just wrote the whole last page of a logfile segment,
> * fsync the segment immediately. This avoids having to go back
> * and re-open prior segments when an fsync request comes along
> * later. Doing it here ensures that one and only one backend will
> * perform this fsync.
> *
> * This is also the right place to notify the Archiver that the
> * segment is ready to copy to archival storage.
> */
> if (openLogOff + pages.size >= XLogSegSize && !ispartialpage)
> {
> XLogPageFlush(&pages, currentIndex);
> issue_xlog_fsync();
> ...
>
> Because of the patch's logic changes, openLogOff is not the right thing
> to be examining here --- we have not yet done a seek to ensure that it
> matches the write start point. (pages.offset + pages.size would have
> worked instead.)
>
> The implication of this is that the code might either fail to do a write
> and fsync when it needs to, or do extra fsyncs that it doesn't need to
> do. I am wondering if the latter could explain your issue. Right
> offhand it doesn't seem like this would lead to enough extra fsyncs
> to account for the amount of slowdown you report --- but there just
> doesn't seem to be anything else in there that could account for it.
>
> I've committed a patch that fixes this and makes some other minor
> improvements (which you probably won't notice given that you're using
> such a large wal_buffers setting). You might like to update to CVS
> tip (make sure you get xlog.c 1.218 or later) and see if things are
> any better or not.
>
> regards, tom lane