Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Дата
Msg-id 3f0b79eb1002180337t1fab1395ve3491256672af15f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Fri, Feb 12, 2010 at 2:29 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> So the only major feature we're missing is the ability to clean up old
> files.

I found another missing feature in new file-based log shipping (i.e.,
standby_mode is enabled and 'cp' is used as restore_command).

After the trigger file is found, the startup process with pg_standby
tries to replay all of the WAL files in both pg_xlog and the archive.
So, when the primary fails, if the latest WAL file in pg_xlog of the
primary can be read, we can prevent the data loss by copying it to
pg_xlog of the standby before creating the trigger file.

On the other hand, the startup process with standby mode doesn't
replay the WAL files in pg_xlog after the trigger file is found. So
failover always causes the data loss even if the latest WAL file can
be read from the primary. And if the latest WAL file is copied to the
archive instead, it can be replayed but a PANIC error would happen
because it's not filled.

We should remove this restriction?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Streaming replication on win32, still broken
Следующее
От: Robert Haas
Дата:
Сообщение: Re: A thought: should we run pgindent now?