On Sun, May 29, 2011 at 4:29 AM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
