Re: Problem with PITR recovery

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Problem with PITR recovery
Дата
Msg-id 4156.1114027158@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Problem with PITR recovery  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Problem with PITR recovery  (Simon Riggs <simon@2ndquadrant.com>)
Re: Problem with PITR recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> Treating shutdown checkpoint markers as xlog switches is possible but
> gives problems since archive_command is a SUSET variable. On replay we
> wouldn't necessarily know whether a shutdown checkpoint was treated as
> an xlog switch when it was written, so we'd need to attempt to switch
> and look beyond the checkpoint marker, just in case. That makes me
> uncomfortable.

[ Forgot to respond to this part... ]

I think the only safe way to handle that would be to define a shutdown
checkpoint record as being effectively an end-of-file record ALWAYS,
whether archiving or not.  This would be rather a problem for initdb,
which would go through a new XLOG segment for each of its multiple
calls to a standalone backend --- on the other hand, it's not real
clear why we couldn't fold initdb down to one bootstrap run and one
plain standalone backend run, which'd cut that problem down to the
point of tolerability.

However, this still begs the question of why we are bothering.
I disagree with the goal in this particular case anyhow: I do not
think it's necessary, safe, nor sane for a shutdown to try to archive
the last XLOG segment.  Even if we fixed the xlog mechanism to end the
file there, I really have a problem with the idea that the archiver
should try to start a fresh archiving cycle at shutdown.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problem with PITR recovery
Следующее
От: Stephen Frost
Дата:
Сообщение: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords