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
commandthat wanted to force sync * commit, then we must flush XLOG immediately.  (We must not allow * asynchronous
commitif there are any non-temp tables to be deleted, * because we might delete the files before the COMMIT record is
flushedto * disk.  We do allow asynchronous commit if all to-be-deleted tables are * temporary though, since they are
lostanyway 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
writesperformed by * the current transaction target temporary or unlogged relations.  Loss * of such a transaction
won'tmatter 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
currenttransaction has not * performed any WAL-logged operation. The latter case can arise if the * only writes
performedby 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'redoing 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
commitif all to-be-deleted tables are temporary * though, since they are lost anyway if we crash.) */
 

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com