Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YDx6O-000874-PS for pgsql-admin@arkaria.postgresql.org; Wed, 21 Jan 2015 15:21:53 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YDx6O-0006rL-8d for pgsql-admin@arkaria.postgresql.org; Wed, 21 Jan 2015 15:21:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YDx6M-0006ox-HF for pgsql-admin@postgresql.org; Wed, 21 Jan 2015 15:21:50 +0000 Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]) by magus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YDx6I-0004z3-3v for pgsql-admin@postgresql.org; Wed, 21 Jan 2015 15:21:49 +0000 Received: by mail-lb0-f177.google.com with SMTP id p9so16483766lbv.8 for ; Wed, 21 Jan 2015 07:21:44 -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=Z3q/9A2seXsIGRsRNby0iloRvI/ZxjBaFFMWeN6Cdao=; b=LgNtDL+8hqdOtS3/gxrRhZdblKC+hdCkOFMtotvdh8rHV/NV7nZg035t7ULwIZCOPZ HPy38vWJqNyFmeLmdfa/PNaLirKR1+5tuQYDADC5JgeE45+32YphJET3clfDw2ZKsLDf d85w45Z8dIawxmjB9CGwdPYgakWpR9zgaCyrXtMJ74WTczPHtlIcFusn9Wn/MQPSv2aa oKbbe22ozu9LKTdgSGi0zezu7EF1HdegUOtVfMsuBlRd6dK8nfdMF4bDKq3A8ip+9eBe RIZ1f7gsIJUx40rHupoNaTQ8ug0igFDxpytzWt9Mlt+59Ix66IgvNwR7eoDAJYhaSC+W JsPw== X-Received: by 10.112.130.65 with SMTP id oc1mr37790466lbb.7.1421853704765; Wed, 21 Jan 2015 07:21:44 -0800 (PST) Received: from [192.168.0.26] ([89.223.47.215]) by mx.google.com with ESMTPSA id bx11sm5008216lbb.14.2015.01.21.07.21.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 07:21:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_56211F35-AE28-442D-9E53-91FCD00CE938" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: PostgreSQL 9.3 synchronous replication From: Sergey Arlashin In-Reply-To: Date: Wed, 21 Jan 2015 19:21:43 +0400 Cc: pgsql-admin Message-Id: <4D515075-C030-4E13-80E8-42C3F6A7FC80@gmail.com> References: To: Matheus de Oliveira 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=_56211F35-AE28-442D-9E53-91FCD00CE938 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 21, 2015, at 3:34 PM, Matheus de Oliveira = wrote: >=20 > On Wed, Jan 21, 2015 at 6:25 AM, Sergey Arlashin = wrote: > 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 >=20 > The exact guarantee depends on synchronous_commit configuration, but = none provides guarantee that the xlog records have been applied and = ready to query, you are right about it. >=20 > =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 > Well, you can use compare the values of pg_current_xlog_location on = the master immediately after commit and pg_last_xlog_replay_location on = the slave (or even use pg_stat_replication.replay_location). >=20 Yes, I understand this. But I was wondering whether it is possible to = somehow force this procedure. Or wait until xlog is applied on slave and = only then consider the transaction committed.=20 Or at least improve the ability of slave to apply xlogs?=20 -- Best regards, Sergey Arlashin > Regards, > --=20 > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br n=EDvel F! > www.dextra.com.br/postgres >=20 --Apple-Mail=_56211F35-AE28-442D-9E53-91FCD00CE938 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 matioli.matheus@gmail.com>= ; wrote:

On Wed, Jan 21, 2015 at 6:25 AM, Sergey Arlashin = <sergeyarl.maillist@gmail.com> = wrote:
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.


The exact guarantee depends = on synchronous_commit configuration, but none provides guarantee that = the xlog records have been applied and ready to query, you are right = about it.

 
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?

Well, = you can use compare the values of pg_current_xlog_location on the master = immediately after commit and pg_last_xlog_replay_location on the slave = (or even use pg_stat_replication.replay_location).


Yes, I = understand this. But I was wondering whether it is possible to somehow = force this procedure. Or wait until xlog is applied on slave and =  only then consider the transaction committed. 
Or = at least improve the ability of slave to apply = xlogs? 

--
Best = regards,
Sergey Arlashin


Regards,
-- =
Matheus de Oliveira
Analista de = Banco de Dados
Dextra Sistemas - MPS.Br n=EDvel F!
www.dextra.com.br/postgres


= --Apple-Mail=_56211F35-AE28-442D-9E53-91FCD00CE938--