Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YDwqY-0007X0-Fo for pgsql-admin@arkaria.postgresql.org; Wed, 21 Jan 2015 15:05:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YDwqX-0003Ki-Oq for pgsql-admin@arkaria.postgresql.org; Wed, 21 Jan 2015 15:05:29 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YDwqW-0003Kb-JW for pgsql-admin@postgresql.org; Wed, 21 Jan 2015 15:05:28 +0000 Received: from mail-lb0-x234.google.com ([2a00:1450:4010:c04::234]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YDwqS-0004YK-Ig for pgsql-admin@postgresql.org; Wed, 21 Jan 2015 15:05:26 +0000 Received: by mail-lb0-f180.google.com with SMTP id b6so14118458lbj.11 for ; Wed, 21 Jan 2015 07:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=x7PdaOLCLEkyiIaCOJFCyttXlpU0If3WRREI8hvZV1Y=; b=R9gXNLRIiFJn70CLnMV1olGiT+i0WHBTZhKcgTfzQeW4JqcaoOK99XxxKstu/Mq4Lx RZe/Na8aYStupePqaS7XLVRKOSpwiTOrHxX1Zb0lKcLMwBMfeX5q0smeUr9C0PbrUXjI qv2EyCGRjj/nrObR3LNAUa8POfVe++25lYieBSJTyPrPjTVj9kIuIBr/RfSNB1sEQoEK zfBbtme8D1kSN0buiGQq6pQ93Se9GxsQEd7/Is9S+PtYoHqytWANx8E8YRTgR52hxG1m RqaJRDvrbmkZn8OhfKgAi1oV+ZEEmd9vx6ckPGRhk4+WQ/ZPw5BYy7km/MOOzm71Dqmb jo/Q== X-Received: by 10.152.30.6 with SMTP id o6mr45296719lah.64.1421852721703; Wed, 21 Jan 2015 07:05:21 -0800 (PST) Received: from [192.168.0.26] ([89.223.47.215]) by mx.google.com with ESMTPSA id d8sm4151219lbk.25.2015.01.21.07.05.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 07:05:20 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6E38019-B9E7-4649-9F77-C72622B49B58" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: PostgreSQL 9.3 synchronous replication From: Sergey Arlashin In-Reply-To: <8491EB60-8281-4890-A02D-DC8FF6630D70@simply.name> Date: Wed, 21 Jan 2015 19:05:20 +0400 Cc: pgsql-admin Message-Id: References: <8491EB60-8281-4890-A02D-DC8FF6630D70@simply.name> To: Vladimir Borodin X-Mailer: Apple Mail (2.1510) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --Apple-Mail=_E6E38019-B9E7-4649-9F77-C72622B49B58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 21, 2015, at 3:19 PM, Vladimir Borodin wrote: >=20 >> 21 =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., =D0=B2 11:25, Sergey Arlashin = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0): >>=20 >> Hi! >>=20 >> Recently I've found out that synchronous replication just guarantees = that the commit has reached the transaction log on the slave. Therefore = that doesn't mean the slave has replayed the transaction log and a query = against the slave will show the transaction's results. >>=20 >> So I'm wondering if there is a way to ensure that once a transaction = is committed the data is available on the slave and I can get it by = executing a query against the slave? >=20 > You should set synchronous_commit =3D on (seems, that right now you = have remote_write). See = http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-= SYNCHRONOUS-COMMIT for more details. Actualy I have 'synchronous_commit =3D on' in my postgresql.conf: postgres=3D# show synchronous_commit ; synchronous_commit -------------------- on (1 row) -- Best regards, Sergey Arlashin --Apple-Mail=_E6E38019-B9E7-4649-9F77-C72622B49B58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 root@simply.name> = wrote:

21 = =D1=8F=D0=BD=D0=B2. 2015 =D0=B3., =D0=B2 11:25, Sergey Arlashin <sergeyarl.maillist@gmail.com> = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):

Hi!

Recently I've found out that synchronous replication just = guarantees that the commit has reached the transaction log on the slave. = Therefore that doesn't mean the slave has replayed the transaction log = and a query against the slave will show the transaction's results.

So I'm wondering if there is a way to ensure = that once a transaction is committed the data is available on the slave = and I can get it by executing a query against the slave?

You should = set synchronous_commit =3D on (seems, that right now you have = remote_write). See http://www.postgresql.org/docs/current/static/runtime-config-wa= l.html#GUC-SYNCHRONOUS-COMMIT for more = details.

Actualy I = have 'synchronous_commit =3D on' in my = postgresql.conf:

postgres=3D# show = synchronous_commit = ;
 synchronous_commit
--------------------
<= div> on
(1 = row)

--
Best = regards,
Sergey Arlashin

= --Apple-Mail=_E6E38019-B9E7-4649-9F77-C72622B49B58--