> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
