On Sun, May 29, 2011 at 4:29 AM, Noah Misch <noah@leadboat.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
