Re: [HACKERS] Database replication... - Mission Critica

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: [HACKERS] Database replication... - Mission Critica
Дата
Msg-id GNELIHDDFBOCMGBFGEFOEEHMCEAA.chriskl@familyhealth.com.au
обсуждение исходный текст
Ответ на Re: [HACKERS] Database replication... - Mission Critica  (Neil Conway <neilc@samurai.com>)
Ответы Re: [HACKERS] Database replication... - Mission Critica  (Bill Gribble <grib@linuxdevel.com>)
Re: [HACKERS] Database replication... - Mission Critica  (Neil Conway <neilc@samurai.com>)
Список pgsql-general
> "Mikheev, Vadim" <VMIKHEEV@sectordata.com> writes:
> > > My presumption would be that if you initialize 2 databases to
> > > a known identical start, have all the same triggers and rules
> > > on both, then send all queries to both databases, you will
> > > have 2 identical databases at the end.
> >
> > This is wrong assumption.
>
> Agreed. Another simple example is:
>
> INSERT INTO foo VALUES (random());

Also, what about if the two servers get the 'begin' command at marginally
different times, then even:

INSERT INTO foo VALUES (CURRENT_TIMESTAMP);

Will be different on each different machine.

In fact, how is this usually handled in 2PC?  You'd have to have the current
time go along with the commit command when it's sent to each server...

Even nastier,  what about if the different postgres servers in the cluster
run on different architectures!  That way you'd get different floating point
results on each machine...

Chris


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

Предыдущее
От: "Robert John Shepherd"
Дата:
Сообщение: Restoring a db dump with tsearch fields fails
Следующее
От: "Thomas T. Thai"
Дата:
Сообщение: Re: Restoring a db dump with tsearch fields fails