From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, Rod Taylor <pg(at)rbt(dot)ca>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
Date: | 2006-02-07 00:07:57 |
Message-ID: | 1139270877.1258.61.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-02-07 00:16:00 | Re: Problems with createlang - windows |
Previous Message | Márcio A. Sepp | 2006-02-06 23:49:24 | Problems with createlang - windows |