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: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>
Subject: Re: Synchronous replication, reading WAL for sending
Date: 2008-12-24 08:20:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

On Wed, Dec 24, 2008 at 2:34 PM, Pavan Deolasee
<pavan(dot)deolasee(at)gmail(dot)com> wrote:
> On Tue, Dec 23, 2008 at 9:12 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> 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?)
>> Another point is that in the future, we really shouldn't require setting up
>> archiving and file-based log shipping using external scripts, when all you
>> want is replication. It should be enough to restore a base backup on the
>> standby, and point it to the IP address of the primary, and have it catch
>> up. This is very important, IMHO. It's quite a lot of work to set up
>> archiving and log-file shipping, for no obvious reason. It's really only
>> needed at the moment because we're building this feature from spare parts.
> I had similar suggestions when I first wrote the high level design doc.
> From the wiki page:
> - WALSender reads from WAL buffers and/or WAL files and sends the
> buffers to WALReceiver. In phase one, we may assume that WALSender can
> only read from WAL buffers and WAL files in pg_xlog directory. Later
> on, this can be improved so that WALSender can temporarily restore
> archived files and read from that too.

You mean that only walsender performs xlog streaming and copying
from pg_xlog serially? I think that this would degrade the performance.
And, I'm worried about the situation that the speed to generate xlog
on the primary is higher than that to copy them to the standby. We
might not be able to start xlog streaming forever.


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Pavan DeolaseeDate: 2008-12-24 08:48:55
Subject: Re: Synchronous replication, reading WAL for sending
Previous:From: Peter EisentrautDate: 2008-12-24 07:55:12
Subject: Re: about truncate

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