Thread: fsynch of pg_log write..

After the discussion about implementing a flag that
would selectively disable fsynch on the pg_log file,
I visited xact.c and tried a little test.  

The code in RecordTransactionCommit looks essentially like
(ignoring stuff related to leaks)

FlushBufferPool /* flush and fsync the data blocks */
TransactionIdCommit /* log the fact that the transaction's done */
FlushBufferPool /* flush and fsync pg_log and whatever else                  has changed during this brief period of
time*/
 

I just added a couple of lines of code that saves
disableFsync and sets it true before the second call
to FlushBufferPool, restoring it to its original state
afterwards.

Running without "-F", my disk is blessedly silent when
I access my web pages that hit the database several times
with read-only selects used to customize the presentation
to the user. 

Cool!

So...does it sound like I'm doing the right thing?




- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at
http://donb.photo.net

Don Baccus wrote:
> 
> FlushBufferPool /* flush and fsync the data blocks */
> TransactionIdCommit /* log the fact that the transaction's done */
> FlushBufferPool /* flush and fsync pg_log and whatever else
>                    has changed during this brief period of time */
> 
> I just added a couple of lines of code that saves
> disableFsync and sets it true before the second call
> to FlushBufferPool, restoring it to its original state
> afterwards.

...

> So...does it sound like I'm doing the right thing?

It's bad in the case of concurrent writes, because of
second FlushBufferPool "flushes whatever else has changed during 
this brief period of time".

Right way is just set some flag in WriteBuffer()/WriteNoReleaseBuffer()
and don't do 

FlushBufferPool
TransactionIdCommit
FlushBufferPool

at all when this flag is not setted.

I'll do it for 6.5.1 if no one else...

Vadim