Re: PostgreSQL + Replicator developer meeting 10/28

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