Re: master and sync-replica diverging

From: "Erik Rijkers" <er(at)xs4all(dot)nl>
To: "Ants Aasma" <ants(at)cybertec(dot)at>
Cc: "Joshua Berkus" <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: master and sync-replica diverging
Date: 2012-05-17 14:24:53
Message-ID: 72ce1d6fd8ad2c1300386b3433386440.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 17, 2012 16:10, Ants Aasma wrote:
> On Thu, May 17, 2012 at 4:53 PM, Erik Rijkers <er(at)xs4all(dot)nl> 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 on disk.  Either my understanding is not correct or there
>> is
>> a bug in postgres sync-rep.
>
> Commit can only return when sync-replica has the data safely on disk,
> but this doesn't mean that it's visible yet.
>
> The sequence of events is in dot notation:
> commit_command -> master_wal_sync -> replica_wal_sync ->
> master_commit_visible -> commit_response
> replica_wal_sync -> replica_replay_wal -> replica_commit_visible
>
> If you issue a select on the replica after getting a commit response
> from master you can see that the query getting a snapshot races with
> replay of the commit record.
>

Ah yes, that makes sense. I hadn't thought of that.

Thank you for that explanation.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Volker Grabsch 2012-05-17 14:26:52 Re: Missing optimization when filters are applied after window functions
Previous Message Ants Aasma 2012-05-17 14:10:05 Re: master and sync-replica diverging