Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 1BDF71337B92 for ; Thu, 10 Mar 2011 16:05:06 -0400 (AST) 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 75016-01 for ; Thu, 10 Mar 2011 20:04:58 +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 4BEB1133655C for ; Thu, 10 Mar 2011 16:04:58 -0400 (AST) Received: by iyb26 with SMTP id 26so1897149iyb.19 for ; Thu, 10 Mar 2011 12:04:58 -0800 (PST) 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=ddCmqwq9pnULXypF58gzQ0uGs0DHJT/0MBaUpt+dkWQ=; b=WdfzJLGkSYsQu9MNVYNVAH9RbVsId6gJbyCCydzJRTmKijeV3PVvR4bGMpujH+fqC1 gB7BjmRIt4T6tKd7dc6BiypSnXN/ViYqc4jABMzKNWXqLhfrizU1FUE+GaIcz3eiSfh4 RMVKOhoeJNlWNojqklgI8phvLaQpybx71p5lA= 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=rhjlg2mCIK7bkWEMd5H6UNDv9d1cuUm0YlndRjvi0A4nlLp2+HcrKWwG38J9yEHVim pN4pYFpn9DvmKfi/O4m4xyWx/UBSwgDgyXcISbsQs5BGbRKhdsn7vIiLhuO0HfaP6oLT LZLT1SUnVqUkS/dpY++v5HpnOJ0tlsf8f1Psk= MIME-Version: 1.0 Received: by 10.42.59.74 with SMTP id l10mr1556919ich.62.1299787498028; Thu, 10 Mar 2011 12:04:58 -0800 (PST) Received: by 10.43.68.208 with HTTP; Thu, 10 Mar 2011 12:04:57 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Mar 2011 15:04:57 -0500 Message-ID: Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. From: Robert Haas To: Fujii Masao Cc: Simon Riggs , PostgreSQL-development 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/700 X-Sequence-Number: 183950 On Mon, Mar 7, 2011 at 6:21 AM, Fujii Masao wrote: > On Mon, Mar 7, 2011 at 5:27 PM, Fujii Masao wrote= : >> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs wrot= e: >>> Efficient transaction-controlled synchronous replication. >>> If a standby is broadcasting reply messages and we have named >>> one or more standbys in synchronous_standby_names then allow >>> users who set synchronous_replication to wait for commit, which >>> then provides strict data integrity guarantees. Design avoids >>> sending and receiving transaction state information so minimises >>> bookkeeping overheads. We synchronize with the highest priority >>> standby that is connected and ready to synchronize. Other standbys >>> can be defined to takeover in case of standby failure. >>> >>> This version has very strict behaviour; more relaxed options >>> may be added at a later date. >> >> Pretty cool! I'd appreciate very much your efforts and contributions. > > Here are another comments: > > =A0 =A0 =A0 =A0if ((wrote_xlog && XactSyncCommit) || forceSyncCommit || n= rels > 0 || > SyncRepRequested()) > > Whenever synchronous_replication is TRUE, we disable synchronous_commit. > But, before disabling that, we should check also max_wal_senders and > synchronous_standby_names? Otherwise, synchronous_commit can > be disabled unexpectedly even in non replication case. Yeah, that's bad. At the risk of repeating myself, I don't think this code should be checking SyncRepRequested() in the first place. If the user has turned off synchronous_commit, then we should just commit asynchronously, even if sync rep is otherwise in force. Otherwise, this if statement is going to get really complicated. The logic is already at least mildly wrong here anyway: clearly we do NOT need to commit synchronously if the transaction has not written xlog, even if sync rep is enabled. > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Let the master know that= we received some data. */ > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 XLogWalRcvSendReply(); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 XLogWalRcvSendHSFeedback(); > > This change completely eliminates the difference between write_location > and flush_location in pg_stat_replication. If this change is reasoable, w= e > should get rid of write_location from pg_stat_replication since it's usel= ess. > If not, this change should be reverted. I'm not sure whether monitoring > the difference between write and flush locations is useful. But I guess t= hat > someone thought so and that code was added. I could go either way on this but clearly we need to do one or the other. > + =A0 =A0 =A0 /* > + =A0 =A0 =A0 =A0* Current location of the head of the queue. All waiters= should have > + =A0 =A0 =A0 =A0* a waitLSN that follows this value, or they are current= ly being woken > + =A0 =A0 =A0 =A0* to remove themselves from the queue. Protected by Sync= RepLock. > + =A0 =A0 =A0 =A0*/ > + =A0 =A0 =A0 XLogRecPtr =A0 =A0 =A0lsn; > > The comment ", or they are currently being woken to remove themselves > from the queue" is no longer required because the proc is currently remov= ed > by walsender. Fixed. > I found some typos. The attached patch fixes them. Committed with minor changes. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company