Re: Integrating Replication into Core - Mailing list pgsql-hackers

From alfranio correia junior
Subject Re: Integrating Replication into Core
Date
Msg-id 4565D278.4010906@lsd.di.uminho.pt
Whole thread Raw
In response to Re: Integrating Replication into Core  (Markus Schiltknecht <markus@bluegap.ch>)
Responses Re: [Replica-hooks-discuss] Integrating Replication ino  (Markus Schiltknecht <markus@bluegap.ch>)
List pgsql-hackers
>> 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 }
executeprocedure <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
startupand 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 ?


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] [PERFORM] Direct I/O issues
Next
From: Tom Lane
Date:
Subject: Re: Vacuum columns in statistics tables