On 16/07/10 20:26, Dimitri Fontaine wrote:
Le 16 juil. 2010 à 12:43, Heikki
Linnakangas<heikki.linnakan...@enterprisedb.com> a écrit :
On 16/07/10 10:40, Fujii Masao wrote:
So we should always prevent the standby from applying any WAL in pg_xlog
unless walreceiver is in progress. That is, if there is no WAL available
in the archive, the standby ignores pg_xlog and starts walreceiver
process to request for WAL streaming.
That completely defeats the purpose of storing streamed WAL in pg_xlog in the
first place. The reason it's written and fsync'd to pg_xlog is that if the
standby subsequently crashes, you can use the WAL from pg_xlog to reapply the
WAL up to minRecoveryPoint. Otherwise you can't start up the standby anymore.
I guess we know for sure that this point has been fsync()ed on the Master, or
that we could arrange it so that we know that?
At the moment we only stream WAL that's already been fsync()ed on the
master, so we don't have this problem, but Fujii is proposing to change
that.
I think that's a premature optimization, and we should not try to change
that. There is no evidence from field (granted, streaming replication is
a new feature) or from performance tests that it is a problem in
practice, or that sending WAL earlier would help. Let's concentrate on
the bare minimum required to make synchronous replication work.
--
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
