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