Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

Rick Gigger <rick@alpinenetworking.com>

From: Rick Gigger <rick@alpinenetworking.com>
To: Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Martijn van Oosterhout <kleptog@svana.org>, Greg Stark <gsstark@mit.edu>, Rod Taylor <pg@rbt.ca>, Qingqing Zhou <zhouqq@cs.toronto.edu>, pgsql-hackers@postgresql.org
Date: 2006-02-07T04:07:41Z
Lists: pgsql-hackers
I was thinking the exact same thing.  Except  the "and just fsync()  
dirty pages on commit" part.  Wouldn't that actually make the  
situation worse?  I thought the whole point of WAL was that it was  
more efficient to fsync all of the changes in one sequential write in  
one file rather than fsyncing all of the separate dirty pages.



On Feb 6, 2006, at 7:24 PM, Christopher Kings-Lynne wrote:

>> 	* Allow WAL logging to be turned off for a table, but the table
>> 	  might be dropped or truncated during crash recovery [walcontrol]
>> 	
>> 	  Allow tables to bypass WAL writes and just fsync() dirty pages on
>> 	  commit.  This should be implemented using ALTER TABLE, e.g. ALTER
>> 	  TABLE PERSISTENCE [ DROP | TRUNCATE | DEFAULT ].  Tables using
>> 	  non-default logging should not use referential integrity with
>> 	  default-logging tables.  A table without dirty buffers during a
>> 	  crash could perhaps avoid the drop/truncate.
>
> This would be such a sweet feature for website session tables...
>
> Chris
>
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>