Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id B6FAC1337B83 for ; Fri, 18 Mar 2011 18:18:37 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 87772-01 for ; Fri, 18 Mar 2011 21:18:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-iy0-f174.google.com (mail-iy0-f174.google.com [209.85.210.174]) by mail.postgresql.org (Postfix) with ESMTP id 3CE16133655C for ; Fri, 18 Mar 2011 18:18:30 -0300 (ADT) Received: by iyb26 with SMTP id 26so4413970iyb.19 for ; Fri, 18 Mar 2011 14:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FWQrqTVpsIEtuuI1iWssCd/jk6HL+HzhV7wijjXG+sc=; b=HcfJzRzzCiGhTYvsNgl6AW3X+clPpRdvMqC65bvcgTFKANtybhng53f2iXVXQbSzMH gGr7SlDNCW9o60MPdTSaRzOtBPMoPrlzIzC/sEpgYWcaPstUaBIm3e171Dvganhtqbap JkFdPMpyZW1asV5d0jArhkyR9BWGPFbmi6F9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jTdIrphEe4dqMowovgncuhJwv90vl45FQpjIK8uiZNwkm9cgaIhv9UcNGdfid+iL9F viM+QTA63MvAD2fEd2SzYKqwrWxCLKyPwaoxnEMgCSpAmJPA1AZrqlz1b4tv0Ft6rozN CljqHN7ZxQ7gb8+s9uRgaiX1OsvedJPtYYT44= MIME-Version: 1.0 Received: by 10.42.196.130 with SMTP id eg2mr2198292icb.495.1300483108450; Fri, 18 Mar 2011 14:18:28 -0700 (PDT) Received: by 10.43.47.129 with HTTP; Fri, 18 Mar 2011 14:18:28 -0700 (PDT) In-Reply-To: <1300476590.18619.18115.camel@ebony> References: <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> <4D74F3AE.9000802@dunslane.net> <4D74FDEC.5040406@enterprisedb.com> <4D74FF15.1070804@dunslane.net> <1299513979-sup-1987@alvh.no-ip.org> <4D832571.5030808@bluegap.ch> <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> Date: Fri, 18 Mar 2011 17:18:28 -0400 Message-ID: Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. From: Robert Haas To: Simon Riggs Cc: Markus Wanner , Heikki Linnakangas , Kevin Grittner , MARK CALLAGHAN , Alvaro Herrera , Andrew Dunstan , Aidan Van Dyk , pgsql-hackers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.72 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, FS_REPLICA=3.599, RCVD_IN_DNSWL_LOW=-0.7, SARE_SPEC_REPLICA=0.72 X-Spam-Level: * X-Archive-Number: 201103/1171 X-Sequence-Number: 184421 On Fri, Mar 18, 2011 at 3:29 PM, Simon Riggs wrote: > On Fri, 2011-03-18 at 20:19 +0100, Markus Wanner wrote: >> Simon, >> >> On 03/18/2011 05:19 PM, Simon Riggs wrote: >> >>> Simon Riggs =A0wrote: >> >>>> In PostgreSQL other users cannot observe the commit until an >> >>>> acknowledgement has been received. >> >> On other nodes as well? =A0To me that means the standby needs to hold ba= ck >> COMMIT of an ACKed transaction, until receives a re-ACK from the master, >> that it committed the transaction there. =A0How else could the slave kno= w >> when to commit its ACKed transactions? > > We could do that easily enough, actually, if we wished. > > Do we wish? Seems like it would be nice, but isn't it dreadfully expensive? Wouldn't you need to prevent the slave from applying the WAL until the master has released the sync rep waiters? You'd need a whole new series of messages back and forth. Since the current solution is intended to support data-loss-free failover, but NOT to guarantee a consistent view of the world from a SQL level, I doubt it's worth paying any price for this. Certainly in the hot_standby=3Doff case it's a nonissue. We might need to think harder about it when and if someone impements an 'apply' level though, because this would seem more of a concern in that case (though I haven't thought through all the details). --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company