Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Why are we WAL-logging FSM operations at all? It's only a hint.
- to ensure self-consistency of the tree, so that if an upper-level page
says there's no free space on pages in range X-Z, there really isn't
- to avoid in-page corruption from torn pages
- to have the FSM useful immediately after recovery (warm standby, mainly)
I think we could give serious consideration to not WAL-logging FSM,
with maybe a tweak here or there to improve the odds of self-repair.
Yeah, I'm starting to lean towards that option too.
Hmm, we could have a vacuum pass over the FSM, fixing any corruption
from the torn-page problem, as well as updating the upper-level pages.
That leaves us just the problem of propagating the FSM information to
the standby, and that we could handle by updating the FSM in the redo
functions of heap and indexes.
That sounds like a good idea anyway, but we still haven't actually
established that the WAL-logging is causing the performance degradation
Zdenek observed.
--
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
