Re: [HACKERS] Infrastructure changes for recovery

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [HACKERS] Infrastructure changes for recovery
Дата
Msg-id 1222649659.4445.1061.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: [HACKERS] Infrastructure changes for recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Infrastructure changes for recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
On Sun, 2008-09-28 at 14:02 -0400, Tom Lane wrote:

> It does nothing AFAICS for the
> problem that when restarting archive recovery from a restartpoint,
> it's not clear when it is safe to start letting in backends.  You need
> to get past the highest LSN that has made it out to disk, and there is
> no good way to know what that is.
>
> Unless we can get past this problem the whole thing seems a bit dead
> in
> the water :-(

I agree the importance of your a problem but don't fully understand the
circumstances under which you see a problem arising.

AFAICS when we set minRecoveryLoc we *never* unset it. It's recorded in
the controlfile, so whenever we restart we can see that it has been set
previously and now we are beyond it. So if we crash during recovery and
then restart *after* we reached minRecoveryLoc then we resume in safe
mode almost immediately. If we crash during recovery before we reached
minRecoveryLoc then we continue until we find it.

There is a loophole, as described on separate post, but that can be
plugged by offering explicit setting of the minRecoveryLoc from
recovery.conf. Most people use pg_start_backup() so do not experience
the need for that.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] get_relation_stats_hook()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Infrastructure changes for recovery