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+.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: knizhnik
Дата:
Сообщение: Re: [ANNOUNCE] IMCS: In Memory Columnar Store for PostgreSQL
Следующее
От: Oskari Saarenmaa
Дата:
Сообщение: [PATCH] pgcrypto: implement gen_random_uuid