Re: Synchronous replication, reading WAL for sending - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Synchronous replication, reading WAL for sending
Date
Msg-id 2e78013d0812240221r66ce7eebr53933478340584ef@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous replication, reading WAL for sending  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Synchronous replication, reading WAL for sending  (Simon Riggs <simon@2ndQuadrant.com>)
List 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 by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Synchronous replication, reading WAL for sending
Next
From: Simon Riggs
Date:
Subject: Re: Archiving control (a part of synch rep patches)