On 08.10.2010 06:41, Fujii Masao wrote:
On Thu, Oct 7, 2010 at 3:01 AM, Markus Wanner<mar...@bluegap.ch> wrote:
Of course, it doesn't make sense to wait-forever on *every* standby that
ever gets added. Quorum commit is required, yes (and that's what this
thread is about, IIRC). But with quorum commit, adding a standby only
improves availability, but certainly doesn't block the master in any
way.
But, even with quorum commit, if you choose wait-forever option,
failover would decrease availability. Right after the failover,
no standby has connected to new master, so if quorum>= 1, all
the transactions must wait for a while.
Sure, the new master can't proceed with commits until enough standbys
have connected to it.
Basically we need to take a base backup from new master to start
the standbys and make them connect to new master.
Do we really need that? I don't think that's acceptable, we'll need to
fix that if that's the case.
I think you're right, streaming replication doesn't work across timeline
changes. We left that out of 9.0, to keep things simple, but it seems
that we really should fix that for 9.1.
You can cross timelines with the archive, though. But IIRC there was
some issue with that too, you needed to restart the standbys because the
standby scans what timelines exist at the beginning of recovery, and
won't notice new timelines that appear after that?
We need to address that, apart from any of the other things discussed
wrt. synchronous replication. It will benefit asynchronous replication
too. IMHO *that* is the next thing we should do, the next patch we commit.
--
Heikki Linnakangas
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
