| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [BUG] Archive recovery failure on 9.3+. |
| Date: | 2014-01-09 20:55:02 |
| Message-ID: | 52CF0CA6.8070208@agliodbs.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01/09/2014 12:05 PM, Heikki Linnakangas wrote:
> Actually, why is the partially-filled 000000010000000000000002 file
> archived in the first place? Looking at the code, it's been like that
> forever, but it seems like a bad idea. If the original server is still
> up and running, and writing more data to that file, what will happen is
> that when the original server later tries to archive it, it will fail
> because the partial version of the file is already in the archive. Or
> worse, the partial version overwrites a previously archived more
> complete version.
Oh! This explains some transient errors I've seen.
> Wouldn't it be better to not archive the old segment, and instead switch
> to a new segment after writing the end-of-recovery checkpoint, so that
> the segment on the new timeline is archived sooner?
It would be better to zero-fill and switch segments, yes. We should
NEVER be in a position of archiving two different versions of the same
segment.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2014-01-09 20:58:01 | Re: Planning time in explain/explain analyze |
| Previous Message | Heikki Linnakangas | 2014-01-09 20:43:15 | Re: [BUG] Archive recovery failure on 9.3+. |