pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Aidan Van Dyk <aidan@highrise.ca>
To: Markus Wanner <markus@bluegap.ch>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: MARK CALLAGHAN <mdcallag@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: Fri, 18 Mar 2011 17:08:11 -0400
Message-ID: <AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com> (raw)
In-Reply-To: <4D83B54C.2030708@bluegap.ch>
References: <E1PwMns-00047O-UU@gemulon.postgresql.org>
	<4D741441.2090704@dunslane.net>
	<1299454125.1696.6138.camel@ebony>
	<4D74896C.5030402@enterprisedb.com>
	<4D74DDFA.70800@dunslane.net>
	<4D74E584.7080409@enterprisedb.com>
	<4D74E9FA.7070202@dunslane.net>
	<AANLkTinkzJ=UrLbThZy2KeQg+SjwYqj2r0mDomMwirB7@mail.gmail.com>
	<4D74F3AE.9000802@dunslane.net>
	<4D74FDEC.5040406@enterprisedb.com>
	<4D74FF15.1070804@dunslane.net>
	<1299513979-sup-1987@alvh.no-ip.org>
	<4D832571.5030808@bluegap.ch>
	<AANLkTi=B+cWE-pQJQM=zoA9=Zr25W7zPPMFvvBe11O4E@mail.gmail.com>
	<1300457958.18619.13780.camel@ebony>
	<4D832B4D020000250003BA98@gw.wicourts.gov>
	<4D837EA2.2070205@enterprisedb.com>
	<1300465171.18619.15193.camel@ebony>
	<4D83B02A.5090105@bluegap.ch>
	<1300476590.18619.18115.camel@ebony>
	<4D83B54C.2030708@bluegap.ch>

On Fri, Mar 18, 2011 at 3:41 PM, Markus Wanner <markus@bluegap.ch> wrote:
> On 03/18/2011 08:29 PM, Simon Riggs wrote:
>> We could do that easily enough, actually, if we wished.
>>
>> Do we wish?
>
> I personally don't see any problem letting a standby show a snapshot
> before the master.  I'd consider it unneeded network traffic.  But then
> again, I'm completely biased.

In fact, we *need* to have standbys show a snapshot before the master.

By the time the master acks the commit to the client, the snapshot
must be visible to all client connected to both the master and the
syncronous slave.

Even with just a single server postgresql cluster, other
clients(backends) can see the commit before the commiting client
receives the ACK.  Just that on a single server, the time period for
that is small.

Sync rep increases that time period by the length of time from when
the slave reaches the commit point in the WAL stream to when it's ack
of that point get's back to the wal sender.  Ideally, that ACK time is
small.

Adding another round trip in there just for a "go almost to $COMIT,
ok, now go to $COMMIT" type of WAL/ack is going to be pessimal for
performance, and still not improve the *guarentees* it can make.

It can only slightly reduce, but not eliminated that window where them
master has WAL that the slave doesn't, and without a complete
elimination (where you just switch the problem to be the slave has the
data that the master doesn't), you haven't changed any of the
guarantees sync rep can make (or not).

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.




view thread (85+ messages)  latest in thread

Message-ID: <AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com>
Permalink:  ../AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com/
Also on:    postgresql.org/message-id/AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: aidan@highrise.ca, markus@bluegap.ch, simon@2ndquadrant.com, heikki.linnakangas@enterprisedb.com, Kevin.Grittner@wicourts.gov, mdcallag@gmail.com, alvherre@commandprompt.com, andrew@dunslane.net, pgsql-hackers@postgresql.org
  Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
  In-Reply-To: <AANLkTimdn_yVBwsNXn9bnOvDmhxHKyLNBqJYab_Oji4z@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox