Re: Integrating Replication into Core

>> I just suggested that we should compare *interfaces* to configure
>> replication (i.e. variable names, grammar, etc), since it looks like
>> we have a bunch of different syntaxes to achieve the same.
>
> The same?
>
> Let's see. I currently have these additional commands:
>
> ALTER DATABASE testdb START REPLICATION
> IN GROUP testgroup USING egcs;
>
> and
>
> ALTER DATABASE testdb ACCEPT REPLICATION
> FROM GROUP testgroup USING egcs;
>

We have the following commands:

SET TRANSACTION MASTER

and

CREATE TRIGGER <name> for { STARTUP | SHUTDOWN |
BEGIN TRANSACTION | COMMIT TRANSACTION | ROLLBACK TRANSACTION }
execute procedure <func> ( <funcargs> )

It is worth noting that none of them have references to replication.
Metainformation on replication is stored in normal tables.

I think that we should discuss requirements first instead of going
towards syntax. The latter is the last step to achieve a common
set of ideas.

I suggest the following road map.

In a database life cycle, there are different events that may be useful
for different replication solutions. For instance, we may say:
- database startup and shutdown
- connection startup and shutdown
- transaction begin, commit, rollback
- statement request
- updates (i.e., insert, delete, update)
- logging

First, we should agree on which events we need to support a set of
replication protocols (e.g., gorda, postgres-r, slony-i and ii, etc).
Then, we should decide how such events will be notified.

In particular, the gorda project decided to use "special triggers" but
any sort of callback would be great for us. We adopted these hooks
because we thought that it would be useful to different applications
(e.g, materialized views).

Third we should discuss what interface would be provided to inject
information into remote replicas. Is the SPI_* interface good ? How
to inject binary data into tables ? I know that PostgreSQL allows to do
that. But is the interface provided enough ? Would not be interesting to
inject things directly into log ?

Fourth, we should have a discussion on locks, high priority
transactions, notifications on blocking, etc...

And finally, we may be able to discuss meta information, syntax, etc...

What do you think ?