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
|
Список | 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 по дате отправления: