Re: WALWriteLock contention

On 05/15/2015 09:06 AM, Robert Haas wrote:

> 2. I don't really understand why WALWriteLock is set up to prohibit
> two backends from flushing WAL at the same time. That seems
> unnecessary. Suppose we've got two backends that flush WAL one after
> the other. Assume (as is not unlikely) that the second one's flush
> position is ahead of the first one's flush position. So the first one
> grabs WALWriteLock and does the flush, and then the second one grabs
> WALWriteLock for its turn to flush and has to wait for an entire spin
> of the platter to complete before its fsync() can be satisfied. If
> we'd just let the second guy issue his fsync() right away, odds are
> good that the disk would have satisfied both in a single rotation.
> Now it's possible that the second request would've arrived too late
> for that to work out, but AFAICS in that case we're no worse off than
> we are now. And if it does work out we're better off. The only

This is a bit out of my depth but it sounds similar to (from a user
perspective) the difference between synchronous and asynchronous commit.
If we are willing to trust that PostgreSQL/OS will do what it is
supposed to do, then it seems logical that what you describe above would
definitely be a net win.

JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.