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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: optimized DROP of multiple tables within a transaction
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Re: How to check whether the row was modified by this transaction before?