Re: Integrating Replication into Core

Поиск
Список
Период
Сортировка
От alfranio correia junior
Тема Re: Integrating Replication into Core
Дата
Msg-id 4565D278.4010906@lsd.di.uminho.pt
обсуждение исходный текст
Ответ на Re: Integrating Replication into Core  (Markus Schiltknecht <markus@bluegap.ch>)
Ответы Re: [Replica-hooks-discuss] Integrating Replication ino
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] [PERFORM] Direct I/O issues
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Vacuum columns in statistics tables