Re: pg_migrator to /contrib in a later 9.0 beta

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: pg_migrator to /contrib in a later 9.0 beta
Дата
Msg-id m2wrvm9jfm.fsf@hi-media.com
обсуждение исходный текст
Ответ на Re: pg_migrator to /contrib in a later 9.0 beta  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_migrator to /contrib in a later 9.0 beta  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<crazy hat on --- but do I ever quit it?>

Andrew Dunstan <andrew@dunslane.net> writes:
> We need to be thinking more now about such a contingency. Postgres use in
> very large installations is now at such a level that requiring a
> pg_dump/pg_restore is really not an option for many users. If pg_migrator is
> not always going to work then we need to be addressing that now, or else it
> is at best a stop-gap. ISTM some sort of page layout versioning scheme might
> be at least part of what we'll need in the medium term.

Would it be on the same complexity level to support recovering WALs from
previous version? On the code maintenance alone it sounds bad enough,
but apart from that?

The idea of course would be then to add an Hot-Standby server running
next PostgreSQL version and fed from current production server. The base
backup would have to either be processed by pg_migrator or we'd have to
open the possibility of starting a slave from a pg_dump, which has been
talked about already.  The change here would be that this initial step
would not be done as part of the maintenance window.

Now you tell me how awful this idea really is :)

Regards,
-- 
dim


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

Предыдущее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: max_standby_delay considered harmful
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: missing file in git repo