Re: switch UNLOGGED to LOGGED

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Leonardo Francalanci <m_lists(at)yahoo(dot)it>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: switch UNLOGGED to LOGGED
Date: 2011-05-31 02:00:43
Message-ID: BANLkTimVoh93_mzipyTduXGaNA7-vx8Jfw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 29, 2011 at 4:29 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> I don't think it is *necessary*.  If we're replaying WAL on a master, we'll also
> be resetting unlogged relations after recovery; what we write or do not write to
> them in the mean time has no functional impact.  Seemed like a sensible
> optimization, but maybe it's premature.

Some jiggering may be necessary, because right now we remove the main
forks at the start of recovery and repopulate them at the end. It's
not immediately obvious to me that that's going to work well with
HEAP_XLOG_NEWPAGE, but then it's not immediately obvious to me that
it's going to work well with a new WAL record type, either. I think
we need a detailed design document for how this is all going to work.
We need to not only handle the master properly but also handle the
slave properly. Consider, for example, the case where the slave
begins to replay the transaction, reaches a restartpoint after
replaying some of the new pages, and then crashes. If the subsequent
restart from the restartpoint blows away the main relation fork, we're
hosed. I fear we're plunging into implementation details without
having a good overall design in mind first.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2011-05-31 02:12:00 Re: Getting a bug tracker for the Postgres project
Previous Message Robert Haas 2011-05-31 01:52:38 Re: Getting a bug tracker for the Postgres project