On Tue, 2008-12-23 at 16:54 +0530, Pavan Deolasee wrote: > On Tue, Dec 23, 2008 at 4:23 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > > > > But, since I cannot obtain consensus from hackers including you, > > I would change my course, and forbid XLogFlush (called from other > > than RecordTransactionCommit) to replicate xlog synchronously > > if asynchronous replication case. > > Since synchronous/asynchronous behavior of replication is tied to a > transaction (even if there is global default) , I don't understand why > we should not ship the xlogs to the standby when xlogs are written on > primary outside of a transaction context. This is quite same as we do > with asynchronous_commit where we flush the xlog to disk at certain > points irrespective of the synchronization set.
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. > > Yes, switchover is one of case example I care. Typically, I care > > about restarting the failed server (original primary) after failover: > > > > I think this is a very important requirement because it's quite > unrealistic to expect that every time there is a failover, fresh > backup is required for the old primary to join back the replication. I personally don't expect that, because we have rsync. If that is a very important requirement then the current software needs to include all the aspects of a feature, not just some of them. Either we include a whole feature or we leave it out. A release will need to stand for 5+ years, so supporting extraneous features is troublesome and wasteful. Currently, Fujii-san has stated he is not planning to allow fast resynchronization in 8.4, so why would we need this? If we were to add fast resynchronisation as a feature in 8.4, then I will be happy to have *all* required changes included. People mention it enough that I would be happy to see the whole feature added in this release -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
