Re: Synchronous replication and read consistency - Mailing list pgsql-general

From Ravi Krishna
Subject Re: Synchronous replication and read consistency
Date
Msg-id CACER=P0VGtgD2=oWjHfddeoEwX1HwUab+j9XTjMai9w8V2cm+Q@mail.gmail.com
Whole thread Raw
In response to Re: Synchronous replication and read consistency  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: Synchronous replication and read consistency
List pgsql-general
"Not necessarily.  There has been discussion of adding a new mode
which will delay the commit on the primary until it is visible on a
synchronous standby, but I don't recall where that left off.  "

Joshua: THis essentially contradicts your statement to me.



On Wed, Jul 29, 2015 at 5:10 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Ravi Krishna <sravikrishna3@gmail.com> wrote:
>
>> As per this:
>>
>> http://www.postgresql.org/docs/current/static/warm-standby.html#SYNCHRONOUS-REPLICATION
>>
>> "When requesting synchronous replication, each commit of a write
>> transaction will wait until confirmation is received that the commit
>> has been written to the transaction log on disk of both the primary
>> and standby server."
>>
>> Does it mean that, on the standby, when PG writes the transaction log
>> on the disk, it also updates the data buffers to make the transaction
>> visible for all sessions.
>
> No, it means that if the primary is hit by a meteor and you promote
> the standby, the data will not have been lost.  The time between
> the successful return of the commit on the primary and the time at
> which the change becomes visible on the standby is normally quite
> small; you may have trouble running into a case where you notice
> it, but it can happen.
>
>> Eg:
>>     On the primary
>>         A big transaction committed
>>     Now if I issue a select on the primary looking for the transaction I
>> committed above, I will get what I want.
>> Will I get the same result if instead of primary I issue the select on
>> the standby.
>
> Not necessarily.  There has been discussion of adding a new mode
> which will delay the commit on the primary until it is visible on a
> synchronous standby, but I don't recall where that left off.  One
> of the issues is that with the current guarantee you need multiple
> replicas to prevent a failure of a standby from stalling the
> primary indefinitely, and you don't have an easy way to know
> *which* replica succeeded in persisting the transaction without
> doing a lot of work.
>
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company


pgsql-general by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: Synchronous replication and read consistency
Next
From: Igor Neyman
Date:
Subject: Re: instr detail