Skip to main content
15 events
when toggle format what by license comment
Nov 22, 2020 at 13:08 history edited Paul White CC BY-SA 4.0
Attempted clean up. Strike out is rarely appropriate - the question should reflect the best current info; the system maintains an automatic edit history for anyone interested.
Nov 14, 2020 at 8:59 vote accept rsmoorthy
Nov 13, 2020 at 18:44 history edited rsmoorthy CC BY-SA 4.0
update with pg_xlogdump output and copy of backup_label
Nov 13, 2020 at 18:33 history edited rsmoorthy CC BY-SA 4.0
update with correct error logs
Nov 13, 2020 at 15:42 answer added Laurenz Albe timeline score: 1
Nov 13, 2020 at 15:28 history edited rsmoorthy CC BY-SA 4.0
extra spaces at the log output end removed on each line.
Nov 13, 2020 at 15:21 comment added rsmoorthy It is vanilla Postgresql, no modifications. That message 'consistent recovery point reached' did not YET happen, before that it aborted. Before it reached 54521, it gave error at 5493D itself. (We have other successful backups which go all the way to the end and gives that 'consistent recovery..' message)
Nov 13, 2020 at 15:16 comment added rsmoorthy 2E is restored, then 2F is restored and then it says redo done at 2E. Probably either 2E or 2F is corrupted? Also pasted at pastebin.com/98J1hS3A
Nov 13, 2020 at 15:13 history edited rsmoorthy CC BY-SA 4.0
Updated more logs properly
Nov 13, 2020 at 15:08 history edited rsmoorthy CC BY-SA 4.0
Updated more logs
Nov 13, 2020 at 6:35 history edited Laurenz Albe CC BY-SA 4.0
added 2 characters in body; edited title
Nov 13, 2020 at 5:15 comment added rsmoorthy pg_stop_backup was definitely run, during the backup. The output of that was stored as backup_label, without which postgres would not start recovery. The recovery went on for 3+ hours, before it stopped here.
Nov 13, 2020 at 5:08 history edited rsmoorthy CC BY-SA 4.0
Added more logs
Nov 12, 2020 at 12:36 review First posts
Nov 12, 2020 at 14:57
Nov 12, 2020 at 12:34 history asked rsmoorthy CC BY-SA 4.0