On Tue, Dec 23, 2008 at 5:55 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
