Re: PITR potentially broken in 9.2

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: PITR potentially broken in 9.2
Дата
Msg-id 10475.1354735024@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: PITR potentially broken in 9.2  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: PITR potentially broken in 9.2  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-bugs
Jeff Janes <jeff.janes@gmail.com> writes:
> Right now if I'm doing a PITR and want to look around before blessing
> the restore, I have to:
> [ do painful stuff ]

Yeah.  The worst thing about this is the cost of stepping too far
forward, but I doubt we can do much about that --- WAL isn't reversible
and I can't see us making it so.  What we can get rid of is the pain
of shutting down to move the recovery target forward.

Another thought here is that it would be good to have some kind of
visibility of the last few potential stop points (timestamps/XIDs),
so that if you do roll too far forward, you have some idea of what
to try after you reset everything.  A zero-order implementation of
that would be to emit LOG messages as we replay each potential
commit, but maybe we can do better.

> I would also be nice if only the superuser is allowed to connect to
> the hot standby when pause_at_recovery_target=true, until after
> pg_xlog_replay_resume() is called.

Uh, why?  Other users won't be able to do anything except look around;
they can't force the database to become read/write.  I can't see that
it's a good idea for recovery to play games with the pg_hba rules;
too much chance of screwing things up for too little benefit.

            regards, tom lane

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PITR potentially broken in 9.2
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: PITR potentially broken in 9.2