> Well, I sort of assumed the design was OK, too, but the more we talk
> about this WAL-logging stuff, the less convinced I am that I really
> understand the problem. :-(
I see. In fact, I think nobody thought about restart points...
To sum up:
1) everything seems ok when in the wal_level = minimal
case. In this case, we fsync everything and at transaction commit
we remove the init fork; in case of a crash, we don't reply
anything (as nothing has been written to the log), and we
remove the main fork as we do now.
2) in the wal_level != minimal case things become more
complicated: if the standby reaches a restart point
and then crashes we are in trouble: it would remove the
main fork at startup, and would reply only a portion of
the table.
I guess the same applies to the master too? I mean:
if we log HEAP_XLOG_NEWPAGEs, reach a checkpoint,
and then crash, at server restart the main fork would be
deleted, and the pages logged on the log couldn't be
replayed. But the problem on the master can be removed
using another type of log instead of HEAP_XLOG_NEWPAGE
(to be replayed by the standbys only).
Is this analysis correct?
Leonardo
