Re: BUG #15346: Replica fails to start after the crash
От | Stephen Frost |
---|---|
Тема | Re: BUG #15346: Replica fails to start after the crash |
Дата | |
Msg-id | 20180828122311.GD3326@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: BUG #15346: Replica fails to start after the crash (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #15346: Replica fails to start after the crash
|
Список | pgsql-bugs |
Greetings, * Andres Freund (andres@anarazel.de) wrote: > On August 28, 2018 11:44:09 AM GMT+09:00, Michael Paquier <michael@paquier.xyz> wrote: > >On Sat, Aug 25, 2018 at 09:54:39AM +0200, Alexander Kukushkin wrote: > >> Why the number of tuples in the xlog is greater than the number of > >> tuples on the index page? > >> Because this page was already overwritten and its LSN is HIGHER than > >> the current LSN! > > > >That's annoying. Because that means that the control file of your > >server maps to a consistent point which is older than some of the > >relation pages. How was the base backup of this node created? Please > >remember that when taking a base backup from a standby, you should > >backup the control file last, as there is no control of end backup with > >records available. So it seems to me that the origin of your problem > >comes from an incorrect base backup expectation? > > Uh, where is that "control file last" bit coming from? pg_basebackup copies it last. The comments should probably be improved as to *why* but my recollection is that it's, at least in part, to ensure the new cluster can't be used until it's actually a complete backup. Thanks! Stephen
Вложения
В списке pgsql-bugs по дате отправления: