Simon Riggs wrote:
On Mon, 2008-09-22 at 20:43 +0300, Heikki Linnakangas wrote:
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrepancy. Corruption within FSM pages is likewise fixed by vacuum and
searchers.
The FSM in a warm standby gets updated by replay of heap CLEAN WAL
records. That means that the FSM will reflect the situation after the
last vacuum, which is better than what we have now, but not quite
up-to-date. I'm worried that this might not be enough...
I hadn't realised you would remove it completely. Did you identify WAL
as the bottleneck?
No. But it seemed like a sensible thing to do.
Is there some mid-way point between every time and almost never
(VACUUM!)?
That's possible. However, if it's not fully WAL-logged, it needs to be
self-correcting, and probably needs to be periodically vacuumed as well.
So you'll get the code complexity of both approaches. I don't think
VACUUM in particular needs to be separately WAL-logged, because we can
easily piggy-back on the HEAP_CLEAN records. The question is whether we
should do the same for every heap insert and update record, or is that
too much overhead?
It looks like truncations do need to be WAL-logged, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
