On Thu, May 17, 2012 16:10, Ants Aasma wrote:
> On Thu, May 17, 2012 at 4:53 PM, Erik Rijkers wrote:
>> The count(*) was done in the way that I showed, i.e. *after* psql had
>> exited. My understanding
>> is
>> that, with synchronous replication 'on' and configured properly, psql could
>> only
On Thu, May 17, 2012 at 4:53 PM, Erik Rijkers wrote:
> The count(*) was done in the way that I showed, i.e. *after* psql had exited.
> My understanding is
> that, with synchronous replication 'on' and configured properly, psql could
> only return *after*
> the sync-replica had the data safely o
On Thu, May 17, 2012 14:32, Joshua Berkus wrote:
> Erik,
>
> Are you taking the counts *while* the table is loading? In sync replication,
> it's possible for
> the counts to differ for a short time due to one of three things:
>
> * transaction has been saved to the replica and confirm message has
Erik,
Are you taking the counts *while* the table is loading? In sync replication,
it's possible for the counts to differ for a short time due to one of three
things:
* transaction has been saved to the replica and confirm message hasn't reached
the master yet
* replica has synched the transa
AMD FX 8120 / centos 6.2 / latest source (git head)
It seems to be quite easy to force a 'sync' replica to not be equal to master by
recreating+loading a table in a while loop.
For this test I compiled+checked+installed three separate instances on the same
machine. The
replica application_nam
