On Tue, May 31, 2011 at 12:25 PM, Leonardo Francalanci <m_lists@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
