On Sat, Dec 11, 2010 at 9:21 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas <robertmh...@gmail.com> wrote: > >> I think the first patch (relpersistence-v4.patch) is ready to commit, >> and the third patch to allow synchronous commits to become >> asynchronous when it doesn't matter (relax-sync-commit-v1.patch) >> doesn't seem to be changing much either, although I would appreciate >> it if someone with more expertise than I have with our write-ahead >> logging system would give it a quick once-over. > > I don't understand what the point of the relax-sync-commit patch is.
Suppose we begin a transaction, write a bunch of data to a temporary table, and commit. Suppose further that synchronous_commit = off. At transaction commit time, we haven't written any XLOG records yet, but we do have an XID assigned because of the writes to the temporary tables. So we'll issue a commit record. Without this patch, since synchronous_commit = off, we'll force that commit record to disk before acknowledging the commit to the user. However, that's not really necessary because if we crash after acknowledging the commit to the user, the temporary tables will disappear anyway, and our XID doesn't exist on disk any place else - thus, whether the commit makes it to disk before the crash or not will be immaterial on restart. If you have a bunch of transactions that make write to temporary (or unlogged) tables but not to any permanent tables, this makes it muuuch faster. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
