From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com> |
Subject: | Re: Synchronous replication, reading WAL for sending |
Date: | 2008-12-24 10:21:11 |
Message-ID: | 2e78013d0812240221r66ce7eebr53933478340584ef@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 24, 2008 at 3:40 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-12-24 10:26:42 | Re: Archiving control (a part of synch rep patches) |
Previous Message | Pavan Deolasee | 2008-12-24 10:10:34 | Re: Synchronous replication, reading WAL for sending |