Re: BUG #15346: Replica fails to start after the crash
От | Stephen Frost |
---|---|
Тема | Re: BUG #15346: Replica fails to start after the crash |
Дата | |
Msg-id | 20180828122150.GC3326@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: BUG #15346: Replica fails to start after the crash (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-bugs |
Greetings, * 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? Yeah, we really need to know how this system was built. If it was built using the low-level pg_start/stop_backup, then which API was used- the old one that creates a backup_label file, or the new API which requires the user to create the backup_label file? I haven't followed this thread very closely, but I wonder if maybe the new API was used, but no backup_label file was created, making PG think it was doing crash recovery instead of restoring from a file-level backup... Thanks! Stephen
Вложения
В списке pgsql-bugs по дате отправления: