On Tue, Dec 23, 2008 at 5:55 PM, Simon Riggs <simon@2ndquadrant.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