On Thu, Dec 1, 2011 at 6:11 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> One possible downside of trying to kick off the fsync more quickly is
> that if there are a continuous stream of background fsyncs going on, a
> process that needs to do an XLogFlush in the foreground (i.e. a
> synchronous_commit=on transaction in the middle of many
> synchronous_commit=off transactions) might be more likely to find an
> fsync already in progress and therefore need to wait until it
> completes before starting the next one, slowing things down.
Waiting until the other one completes is how it currently is
implemented, but is it necessary from a correctness view? It seems
like the WALWriteLock only needs to protect the write, and not the
sync (assuming the sync method allows those to be separate actions),
and that there could be multiple fsync requests from different
processes pending at the same time without a correctness problem.
After dropping the WALWriteLock and doing the fsync, it would then
have to take the lock again or maybe just a spinlock to update the
accounting for how far the log has been flushed. So rather than one
committing process blocking on fsync and bunch of others blocking on
WALWriteLock, you could have all of them blocking on different fsyncs
and let the kernel deal with waking them up. I don't know at all
whether this would actually be an improvement, assuming it would even
be safe. Reading the xlog.c code, it is hard to tell which
designs/features are there for safety and which ones are there for
suspected performance reasons.
Sorry for high-jacking your topic, it is just something I had been
thinking about for a while.
Cheers,
Jeff