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

Re: switch UNLOGGED to LOGGED

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Leonardo Francalanci <m_lists(at)yahoo(dot)it>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: switch UNLOGGED to LOGGED
Date: 2011-06-03 16:05:41
Message-ID: BANLkTikW8T1PYsVQYvPxSOeMb0=J9xxtvQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, May 31, 2011 at 12:25 PM, Leonardo Francalanci <m_lists(at)yahoo(dot)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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-06-03 16:07:55
Subject: Re: About bug #6049
Previous:From: Robert HaasDate: 2011-06-03 16:03:40
Subject: Re: BLOB support

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