Hi,
On Wed, Dec 24, 2008 at 1:48 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Tue, 2008-12-23 at 17:42 +0200, Heikki Linnakangas wrote:
>
>> As the patch stands, whenever XLOG segment is switched in XLogInsert, we
>> wait for the segment to be sent to the standby server. That's not good.
>> Particularly in asynchronous mode, you'd expect the standby to not have
>> any significant ill effect on the master. But in case of a flaky network
>> connection, or a busy or dead standby, it can take a long time for the
>> standby to respond, or the primary to give up. During that time, all WAL
>> insertions on the primary are blocked. (How long is the default TCP
>> timeout again?)
>
> Ugh, didn't see that. Get rid of that. We managed to get rid of the
> fsync of the control file when we changed WAL file at start of 8.3. That
> had a major effect on performance, via reduced response time profiles.
> No need to re-introduce a delay in the same place.
Yes, I will get rid of it. It's only async case? both(async & sync)?
>> For those reasons, we need a way to send arbitrary ranges of WAL from
>> primary to standby. The current method where the WAL is read from
>> wal_buffers obviously only works for very recent WAL pages that are
>> still in wal_buffers. The design should be changed so that instead of
>> reading from wal_buffers, the WAL is read from filesystem.
Filesystem you say is only pg_xlog? If it includes archive, we might have
to execute restore command in order to read WAL from filesystem?
> If you are seriously suggesting these things now then I'd like to see
> some diagrams, designs and descriptions so we can all understand what is
> being suggested, how it will cope with all the current requirements.
I also want.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center