Re: unlogged tables
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2010-12-15T07:20:17Z
Lists: pgsql-hackers
On 14.11.2010 02:16, Robert Haas wrote: > 3. The third patch (relax-sync-commit-v1) allows asynchronous commit > even when synchronous_commit=on if the transaction has not written > WAL. Of course, a read-only transaction won't even have an XID and > therefore won't need a commit record, so what this is really doing is > allowing transactions that have written only to temp - or unlogged - > tables to commit asynchronously. This should be OK, because if the > system crashes before the commit record hits the disk, we haven't > really lost anything we wouldn't lose anyway: the temp tables will > disappear on restart, and the unlogged ones will be truncated. This > path actually could be applied independently of the first two, if I > adjusted the comments a bit. Looks ok. I'd suggest rewording this comment though: /* * Check if we want to commit asynchronously. If we're doing cleanup of * any non-temp rels or committing any command that wanted to force sync * commit, then we must flush XLOG immediately. (We must not allow * asynchronous commit if there are any non-temp tables to be deleted, * because we might delete the files before the COMMIT record is flushed to * disk. We do allow asynchronous commit if all to-be-deleted tables are * temporary though, since they are lost anyway if we crash.) Otherwise, * we can defer the flush if either (1) the user has set synchronous_commit * = off, or (2) the current transaction has not performed any WAL-logged * operation. This latter case can arise if the only writes performed by * the current transaction target temporary or unlogged relations. Loss * of such a transaction won't matter anyway, because temp tables will be * lost after a crash anyway, and unlogged ones will be truncated. */ It's a bit hard to follow, as it first lists exceptions on when we must flush XLOG immediately, and then lists conditions on when we can skip it. How about: /* * Check if we can commit asynchronously. We can skip flushing the XLOG * if synchronous_commit=off, or if the current transaction has not * performed any WAL-logged operation. The latter case can arise if the * only writes performed by the current transaction target temporary or * unlogged relations. Loss of such a transaction won't matter anyway, * because temp tables will be lost after a crash anyway, and unlogged * ones will be truncated. * * However, if we're doing cleanup of any non-temp rels or committing * any command that wanted to force sync commit, then we must flush * XLOG immediately anyway. (We must not allow asynchronous commit if * there are any non-temp tables to be deleted, because we might delete * the files before the COMMIT record is flushed to disk. We do allow * asynchronous commit if all to-be-deleted tables are temporary * though, since they are lost anyway if we crash.) */ -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com