Re: Tracking latest timeline in standby mode
От | Fujii Masao |
---|---|
Тема | Re: Tracking latest timeline in standby mode |
Дата | |
Msg-id | AANLkTim-1_=UHHRbZyx059YoQJVSMmmVHiAqT-qgVK_k@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Tracking latest timeline in standby mode (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Tracking latest timeline in standby mode
Re: Tracking latest timeline in standby mode |
Список | pgsql-hackers |
On Mon, Nov 1, 2010 at 8:32 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Yeah, that's one approach. Another is to validate the TLI in the xlog page > header, it should always match the current timeline we're on. That would > feel more robust to me. Yeah, that seems better. > We're a bit fuzzy about what TLI is written in the page header when the > timeline changing checkpoint record is written, though. If the checkpoint > record fits in the previous page, the page will carry the old TLI, but if > the checkpoint record begins a new WAL page, the new page is initialized > with the new TLI. I think we should rearrange that so that the page header > will always carry the old TLI. Or after rescanning the timeline history files, what about refetching the last applied record and checking whether the TLI in the xlog page header is the same as the previous TLI? IOW, what about using the header of the xlog page including the last applied record instead of the following checkpoint record? Anyway ISTM we should also check that the min recovery point is not ahead of the TLI switch location. So we need to fetch the record in the min recovery point and validate the TLI of the xlog page header. Otherwise, the database might get corrupted. This can happen, for example, when you remove all the WAL files in pg_xlog directory and restart the standby. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: