> The idea is to design a single set of hooks that can be used to
> implement an entire class of replication. This only makes sense after
> existing solutions come to some agreement. I view that as a first step,
> assuming that it is necessary to alter the core in order to implement
> the class of replication in question.
>
> Once that step is complete, ideally you'd be able to implement Postgres-
> R without having to patch the postgresql backend to accomplish it
> (except for maybe adding the syntax for your solution). Then, when a
> syntax is agreed upon, you won't need to patch the backend at all. Isn't
> that the goal, to be able to implement your replication without patching
> the backend?
We should go in that direction.
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...
Regards,
Alfranio Junior.