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

I have split up the TODO items as:* Allow WAL logging to be turned off for a table, but the table  might be dropped or
truncatedduring 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
buffersduring a  crash could perhaps avoid the drop/truncate.* Allow WAL logging to be turned off for a table, but the
tablewould  avoid being truncated/dropped [walcontrol]  To do this, only a single writer can modify the table, and
writes must happen only on new pages so the new pages can be removed during  crash recovery.  Readers can continue
accessingthe table.  Such  tables probably cannot have indexes.  One complexity is the handling  of indexes on TOAST
tables.

I think the first one is possible, while the second has many
complexities that make its implementation suspect.

---------------------------------------------------------------------------

Simon Riggs wrote:
> On Fri, 2006-02-03 at 22:29 -0500, Bruce Momjian wrote:
> 
> > Based on this, I think we should just implement the TRUNCATE/DROP option
> > for the table, and avoid the idea of allowing non-logged operations on a
> > table that has any data we want recovered after a crash.
> 
> Well the only other option is this:
> 
> Implement an UNDO at abort like we do for DDL, which would truncate the
> table back down to the starting point. That can be made to work for both
> cases.
> 
> In addition if the starting point was > 0 then we'd need to perform a
> VACUUM style operation to remove any index pointers with tids into the
> to-be-truncated blocks. That would then make it work for the
> with-indexes and/or with-toast cases.
> 
> If starting point == 0 we would just truncate the indexes and toast
> stuff too.
> 
> Most importantly we'd need to do this at recovery time. That bit will
> take a bit of work to make it happen right, but seems doable.
> 
> So we cover both cases at once, using one lot of logic. But there is a
> fair amount of work there, so I'll need to consider whether its 8.2
> material or not.
> 
> Best Regards, Simon Riggs
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073