
> 	/*
> 	 * If no one shared buffer was changed by this transaction then
> 	 * we don't flush shared buffers and don't record commit status.
> 	 */
> 	if (SharedBufferChanged)
> 	{
> 		FlushBufferPool();
> 		sync();
> 		if (leak)
> 			ResetBufferPool();
> 
> 		/*
> 		 *	have the transaction access methods 
> record the status
> 		 *	of this transaction id in the pg_log relation.
> 		 */
> 		TransactionIdCommit(xid);
> 
> 		/*
> 		 *	Now write the log info to the disk too.
> 		 */
> 		leak = BufferPoolCheckLeak();
> 		FlushBufferPool();

Would it be a win if this second call to FlushBufferPool would only fsync
pg_log ?
Since if I read correctly, this call will also flush IO from other sessions.

If I remember correctly I did a test by commenting the second
FlushBufferPool call,
but that resulted in some regression failures.
This call would actually not be needed for DB consistency issues (ACID). 
It is only needed for Client/Server consistency 
(client got commit ok, but server does rollback on crash).

> 		sync();
> 	}

Wed, 9 Feb 2000 16:50:24 +0100 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: [HACKERS] TODO item 