Re: Sync Rep: First Thoughts on Code

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>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sync Rep: First Thoughts on Code
Date: 2008-12-23 13:06:47
Message-ID: 2e78013d0812230506v6a2b58f2raba1f46040f0a103@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 23, 2008 at 5:55 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>
> We stream constantly from primary to standby. That point is not being
> debated. The issue is whether we should add additional synchronisation
> points (i.e. additional times we need to wait) into the WAL stream.
> Currently, I have said no because this has no purpose in the current
> design: definitely not performance, not robustness, not code clarity.
>
> Specifically, we're talking about slowing down WAL flushes required
> because of dirty page replacement, amongst others. That's not something
> I want to see slowed down on a server that has specifically opted for
> asynchronous replication, presumably because of a slow link. The other
> call points are also potential contention points.

So we would still be sending WAL to standby at XLogWrite time (and I
think that's necessary). The question is whether we should wait for
standby ack at XLogFlush time, right ? Hmm. I think the argument for
that would be what Fujii-san described for maintaining consistency
between data and WAL. I agree with you that we should add additional
synchronization points only if they give us any real value in
administrating replication setup. Personally, I would like to have a
simple setup where I can initially setup primary and standby and they
continue to work in a single-failure mode without any additional
administrative overhead (such as rsync). But that's just me and I
don't know what the preferred option in the field.

BTW, I won't be too much worried about dirty buffer case because the
WAL synchronization at that point usually occurs much later than the
WAL is actually sent to the standby. I would imagine that most of the
time WAL would have made to standby by that time.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2008-12-23 13:07:46 Re: Lock conflict behavior?
Previous Message Simon Riggs 2008-12-23 12:52:37 Re: Hot standby and b-tree killed items