Alvaro Herrera wrote:
Hannu Krosing wrote:
On Tue, 2008-10-28 at 15:18 -0700, Joshua Drake wrote:
Will there be an helper application for setting up and configuring
changes in replication. or will it all be done using added SQL
commands ?
Well, the interface I work on is all SQL commands :-)
Case in point. To replicate a table currently you do this:
ALTER TABLE foo ENABLE REPLICATION;
ALTER TABLE foo ENABLE REPLICATION ON SLAVE 0;
Will Slave tables be kind-of-read-only like Slony slaves ? Or even
_really_ read only like Simon's Hot Standby ?
Heh -- they are read only, and they turn into read-write when the slave
promotes. I'm not sure what kind does that make it :-)
The relation is locked read only if the relation is considered
replicated. If it is not replicated you could write to it.
Did the plans got any clearer during this meeting ?
Not really; we didn't talk about that.
Right the meeting was about two specific things. Which are the core
features for 1.9. MCP architecture and DDL replication.
Hmm I am not sure. We are pretty deep into the core and only use
triggers for GRANT/REVOKE/CREATE ROLE .
By the way, why did you choose "pretty deep into the core" approach
instead of triggers ?
Speed maybe? I don't know.
Well actually that was my decision years ago and it was made for two
reasons:
1. Speed
2. Lots of people think trigger replication is a hack. (not interested
in arguing just stating an observation).
One of the core requirements of the original replicator which can still
be seen today AND is a requirement of 1.9 as well is:
Though shall not cause grief to thy master even if thy replicates many
children.
That is where the original idea of the MCP came from. They theory was,
we could have 50 slaves and the master wouldn't care.
I mean, you probably end up duplicating (or missing) lots of
postgreSQL-s internal goodness instead of just using what is already
available ?
Well yes and no. We have made more and more use of the internal
postgresql code through 1.7, 1.8. I expect that trend will continue. A
hairy wart would be the use of own log, but hey its BSD if someone can
figure out how to make it work with WAL and not lose the feature set we
have I would not vote against it and would happily except the patch
(assuming technical sign off by Alvaro and Alexey).
I hope something useful will come out of this too, though I hoped that
it already had some advantages over trigger-based replication, like
Well it does. We can replicate large objects for example and our user
experience is far more friendly than anything else.
ability to replicate DDL .
That is what 1.9 is all about. Remember that the "hope" (no laughing
now) is that 1.9 will hit for 8.3 and 8.4 around the time 8.4 releases.
So this isn't a year away.
I fear that our approach to replication is so ad-hoc that there's not
much to be gained from elsewhere. Replicator is pretty much a fork
that's not likely to yield anything useful to upstream.
That is probably true.
Sincerely,
Joshua D. Drake
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
