Re: Serious problem: media recovery fails after system or PostgreSQL crash
От | MauMau |
---|---|
Тема | Re: Serious problem: media recovery fails after system or PostgreSQL crash |
Дата | |
Msg-id | 972E1E3640674093B1CF8C329D03F80F@maumau обсуждение исходный текст |
Ответ на | Re: Serious problem: media recovery fails after system or PostgreSQL crash (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Serious problem: media recovery fails after system
or PostgreSQL crash
|
Список | pgsql-hackers |
From: "Tom Lane" <tgl@sss.pgh.pa.us> > Well, that's unfortunate, but it's not clear that automatic recovery is > possible. The only way out of it would be if an undamaged copy of the > segment was in pg_xlog/ ... but if I recall the logic correctly, we'd > not even be trying to fetch from the archive if we had a local copy. No, PG will try to fetch the WAL file from pg_xlog when it cannot get it from archive. XLogFileReadAnyTLI() does that. Also, PG manual contains the following description: http://www.postgresql.org/docs/9.1/static/continuous-archiving.html#BACKUP-ARCHIVING-WAL WAL segments that cannot be found in the archive will be sought in pg_xlog/; this allows use of recent un-archived segments. However, segments that are available from the archive will be used in preference to files in pg_xlog/. So, continuing recovery by changing the emode to LOG would work. What do you think about this fix? > I think having PG automatically destroy archive files is bordering on > insane. I agree. Before that, PG cannot know the archive location, so PG cannot delete the partially filled archive files. Regards MauMau
В списке pgsql-hackers по дате отправления: