Skip site navigation (1) Skip section navigation (2)

Re: Synchronous replication, reading WAL for sending

From: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "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-23 17:51:17
Message-ID: 3f0b79eb0812230951q3ac34bbfie50094e4a15fea29@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

On Wed, Dec 24, 2008 at 1:48 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-12-23 17:53:55
Subject: Re: Synchronous replication, network protocol
Previous:From: Simon RiggsDate: 2008-12-23 17:37:03
Subject: Re: Sync Rep: First Thoughts on Code

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group