Re: patch proposal

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: patch proposal
Дата
Msg-id 20160818092051.GL4028@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: patch proposal  (Venkata B Nagothi <nag1010@gmail.com>)
Ответы Re: patch proposal  (Venkata B Nagothi <nag1010@gmail.com>)
Список pgsql-hackers
* Venkata B Nagothi (nag1010@gmail.com) wrote:
> On Wed, Aug 17, 2016 at 11:27 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > * Venkata B Nagothi (nag1010@gmail.com) wrote:
> > > Agreed. Additional option like "pause" would. As long as there is an
> > option
> > > to ensure following happens if the recovery target is not reached -
> > >
> > >  a) PG pauses the recovery at the end of the WAL
> > >  b) Generates a warning in the log file saying that recovery target point
> > > is not reached (there is a patch being worked upon on by Thom on this)
> > >  c) Does not open-up the database exiting from the recovery process by
> > > giving room to resume the replay of WALs
> >
> > One thing to consider is just how different this is from simply bringing
> > PG up as a warm standby instead, with the warning added to indicate if
> > the recovery point wasn't reached.
>
> I am referring to a specific scenario (performing point-in time recovery)
> where-in a DBA attempts to bring up a standalone PG instance by restoring
> the backup and performing recovery to a particular recover target (XID,
> time or a named restore point) in the past by replaying all the available
> WAL archives, which is not quite possible through a warm-standby setup.
>
> Warm standby is more of a high-availability solution and i do not think so,
> it addresses PITR kind of situation.

No, a warm standby is one which just plays through the WAL but doesn't
bring the database up or start its own set of WAL, which is what you're
asking about.

Thanks!

Stephen

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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Fix comment in ATExecValidateConstraint
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid