Re: [HACKERS] Database replication... - Mission Critica - Mailing list pgsql-general

From Christopher Kings-Lynne
Subject Re: [HACKERS] Database replication... - Mission Critica
Date
Msg-id GNELIHDDFBOCMGBFGEFOEEHMCEAA.chriskl@familyhealth.com.au
Whole thread Raw
In response to Re: [HACKERS] Database replication... - Mission Critica  (Neil Conway <neilc@samurai.com>)
Responses Re: [HACKERS] Database replication... - Mission Critica  (Bill Gribble <grib@linuxdevel.com>)
Re: [HACKERS] Database replication... - Mission Critica  (Neil Conway <neilc@samurai.com>)
List 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 by date:

Previous
From: "Robert John Shepherd"
Date:
Subject: Restoring a db dump with tsearch fields fails
Next
From: "Thomas T. Thai"
Date:
Subject: Re: Restoring a db dump with tsearch fields fails