On Tue, May 31, 2011 at 12:25 PM, Leonardo Francalanci <m_li...@yahoo.it> wrote: >> 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.
Yeah, that seems like it should work. > 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). I think that's about right, except that I feel we're missing some trick here that's needed to make all this work out nicely. Somehow we need to maintain some state that an unlogged->logged conversion is in progress; that state needs to then get cleaned up at commit or abort time (including implicit abort). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers