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



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to