Re: Synchronous replication, reading WAL for sending

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Synchronous replication, reading WAL for sending
Дата
Msg-id 2e78013d0812240221r66ce7eebr53933478340584ef@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Synchronous replication, reading WAL for sending  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Synchronous replication, reading WAL for sending  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Wed, Dec 24, 2008 at 3:40 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
>
> If we want to speed up recovery more, I think we'll see the need for an
> additional process to do WAL CRC checks.
>

Yeah, any such helper process along with other optimizations would
certainly help. But I can't still believe that on a high load, high
end setup, single recovery process without any read-ahead for data
blocks, can keep pace with the WAL generated by hundreds of processes
at the primary and shipped over a high speed link to standby.

BTW, on a completely different note, given that the entire recovery is
based on physical redo, are there any inherent limitations that we
can't do parallel recovery where different recovery processes apply
redo logs to completely independent set of data blocks ? I also
sometimes wonder why we don't have block level recovery when a single
block in the database is corrupted. Can't this be done by just
selectively applying WAL records to that particular block ? If it's
just because nobody had time/interest to do this, then it's OK, but I
wonder if there are any design issues.

Thanks,
Pavan

-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com


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

Предыдущее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Synchronous replication, reading WAL for sending
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Archiving control (a part of synch rep patches)