Re: [BUG] Archive recovery failure on 9.3+.
От | Heikki Linnakangas |
---|---|
Тема | Re: [BUG] Archive recovery failure on 9.3+. |
Дата | |
Msg-id | 52CF0761.20205@vmware.com обсуждение исходный текст |
Ответ на | Re: [BUG] Archive recovery failure on 9.3+. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUG] Archive recovery failure on 9.3+.
|
Список | pgsql-hackers |
On 01/09/2014 10:16 PM, Tom Lane wrote: > Heikki Linnakangas <hlinnakangas@vmware.com> writes: >> Actually, why is the partially-filled 000000010000000000000002 file >> archived in the first place? ... > >> So, the rationale is that otherwise it would take a long time until that >> segment is archived. To be precise, I don't think the segment with the >> old TLI would ever be archived without the above, but the same segment >> on the new timeline would, after it fills up. > >> 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? > > Don't we want to archive both? If you want to recover to the end of the > old timeline, you're going to need that file too, no? Hmm. It should be the responsibility of the original server to archive the segment on the old timeline. Mind you, partial segments are never archived, except for this one case, so how did the old segment find its way to the new server? A few possibilities come to mind: the DBA manually copied it from the old server to pg_xlog, it was streamed by streaming replication, or it was included in a base backup. The OP's test script resembles the base backup case. In all of those cases, I don't think it's the new server's responsibility to archive it. If it was copied to pg_xlog manually, the administrator may also copy it to the archive if he feels like it. If it was streamed from a live server, the original server should take care of it. If it was included in a backup, well, it's included in the backup so it doesn't necessarily need to be archived. - Heikki
В списке pgsql-hackers по дате отправления: