Re: Proposal: Commit timestamp

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Proposal: Commit timestamp
Дата
Msg-id D08371E0-2C8E-40C1-B680-C493E3FAE903@decibel.org
обсуждение исходный текст
Ответ на Re: Proposal: Commit timestamp  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Список pgsql-hackers
Something worth noting... the only places I've actually seen MM  
replication implemented, each master was in fact still responsible  
for it's own set of data. It was essentially something that you could  
really do with Slony, if you could tolerate the extreme complexity  
that would be involved. It might well be worth focusing on that case  
first, before trying to come up with a perfect last-committed mechanism.

On Feb 5, 2007, at 5:20 AM, Zeugswetter Andreas ADI SD wrote:

> I think you are completely ignoring practicability. Or are you saying,
> that such a system exists and works for e.g. a loosly connected  
> group of
> laptop field agents that only sporadically have a connection to the
> cluster.
>
> I think Jan's definition gives a pragmatic solution to the problem,
> and will be able to give "good" automatic conflict resolution.
>
> It has downsides he stated, and cannot guarantee 100% correct  
> automatic
> conflict
> resolution in case of connection loss, but I am quite sure you are not
> able to do
> better, without loosing yourself in theory.
>
> e.g. assume all clocks vary by no more than 30 seconds when
> disconnected, you can
> require manual (or rule based) resolution to all conflicts that  
> vary by
> less than
> 1 minute.

--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Andrew Hammond"
Дата:
Сообщение: Re: 10 weeks to feature freeze (Pending Work)
Следующее
От: Markus Schiltknecht
Дата:
Сообщение: Re: Proposal: Commit timestamp