On Tue, 2008-12-23 at 16:54 +0530, Pavan Deolasee wrote:
> On Tue, Dec 23, 2008 at 4:23 PM, Fujii Masao <masao.fujii@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.comPostgreSQL Training, Services and Support
