Re: unlogged tables

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