On Mon, May 14, 2012 at 9:56 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, May 14, 2012 at 9:06 AM, Bruce Momjian <br...@momjian.us> wrote: > >> This is the git commit message: >> >> Make group commit more effective. >> >> When a backend needs to flush the WAL, and someone else is already >> flushing >> the WAL, wait until it releases the WALInsertLock and check if we still >> need >> to do the flush or if the other backend already did the work for us, >> before >> acquiring WALInsertLock. This helps group commit, because when the WAL >> flush >> finishes, all the backends that were waiting for it can be woken up in one >> go, and the can all concurrently observe that they're done, rather than >> waking them up one by one in a cascading fashion. >> >> This is based on a new LWLock function, LWLockWaitUntilFree(), which has >> peculiar semantics. If the lock is immediately free, it grabs the lock and >> returns true. If it's not free, it waits until it is released, but then >> returns false without grabbing the lock. This is used in XLogFlush(), so >> that when the lock is acquired, the backend flushes the WAL, but if it's >> not, the backend first checks the current flush location before retrying. >> >> Original patch and benchmarking by Peter Geoghegan and Simon Riggs, >> although >> this patch as committed ended up being very different from that. >> >> (Heikki Linnakangas) >> >> Is that commit message inaccurate? > > I think the commit message is accurate, other than saying > WALInsertLock where it meant WALWriteLock.
Sorry, wrong number of negations. "I think the commit message is accurate, other than" Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
