pg_upgrade resets timeline to 1

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема pg_upgrade resets timeline to 1
Дата
Msg-id 20150527154009.GA20160@msg.df7cb.de
обсуждение исходный текст
Ответы Re: pg_upgrade resets timeline to 1  (Bruce Momjian <bruce@momjian.us>)
Re: pg_upgrade resets timeline to 1  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian <bruce@momjian.us>
Date:   Sat May 16 00:40:18 2015 -0400
   pg_upgrade:  force timeline 1 in the new cluster
   Previously, this prevented promoted standby servers from being upgraded   because of a missing WAL history file.
(Timeline1 doesn't need a   history file, and we don't copy WAL files anyway.)
 

Pardon me for starting a fresh thread, but I couldn't find where this
was discussed.

I've just had trouble getting barman to work again after a 9.1->9.4.2
upgrade, and I think part of the problem was that the WAL for this
cluster got reset from timeline 2 to 1, which made barman's incoming
WALs processor drop the files, probably because the new filename
0001... is now "less" than the 0002... before.

I don't expect to be able to recover through a pg_upgrade operation,
but pg_upgrade shouldn't make things more complicated than they should
be for backup tools. (If there's a problem with the history files,
shouldn't pg_upgrade copy them instead?)

In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
timeline to make sure the archive_command doesn't clobber any files
from the old cluster when reused in the new cluster?

https://bugs.debian.org/786993

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/



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

Предыдущее
От: Ted Toth
Дата:
Сообщение: rhel6 rpm file locations
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Run pgindent now?