From: | "MauMau" <maumau307(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Serious problem: media recovery fails after system or PostgreSQL crash |
Date: | 2012-12-06 22:45:14 |
Message-ID: | 972E1E3640674093B1CF8C329D03F80F@maumau |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-06 22:47:05 | Re: Re: How to check whether the row was modified by this transaction before? |
Previous Message | Tomas Vondra | 2012-12-06 22:38:59 | Re: PATCH: optimized DROP of multiple tables within a transaction |