On Thu, 2009-01-29 at 09:34 +0200, Heikki Linnakangas wrote: > It does *during recovery*, before InitXLogAccess is called. Yeah, it's > harmless currently. It would be pretty hard to keep it up-to-date in > bgwriter and other processes. I think it's better to keep it at 0, > which is clearly an invalid value, than try to keep it up-to-date and > risk using an old value. TimeLineID is not used in a lot of places, > currently. It might be a good idea to add some "Assert(TimeLineID != > 0)" to places where it used.
Agreed. TimeLineID is a normal-running concept used for writing WAL. Perhaps we should even solidify the meaning of TimeLineID == 0 as "cannot write WAL". I see a problem there for any process that exists both before and after recovery ends, which includes bgwriter. In that case we must not flush WAL before recovery ends, yet afterwards we *must* flush WAL. To do that we *must* have a valid TimeLineID set. I would suggest we put InitXLogAccess into IsRecoveryProcessingMode(), so if the mode changes we immediately set everything we need to allow XLogFlush() calls to work correctly. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
