Skip site navigation (1) Skip section navigation (2)


From: Leonardo Francalanci <m_lists(at)yahoo(dot)it>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: switch UNLOGGED to LOGGED
Date: 2011-05-31 16:25:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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?


In response to


pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2011-05-31 16:32:43
Subject: Re: Getting a bug tracker for the Postgres project
Previous:From: Jaime CasanovaDate: 2011-05-31 16:24:09
Subject: Re: creating CHECK constraints as NOT VALID

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group