Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frf6X-0005mY-Tw for pgsql-admin@arkaria.postgresql.org; Mon, 20 Aug 2018 08:00:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1frf6T-0005HS-AH for pgsql-admin@arkaria.postgresql.org; Mon, 20 Aug 2018 07:59:57 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frf6S-0005HL-Uv for pgsql-admin@lists.postgresql.org; Mon, 20 Aug 2018 07:59:57 +0000 Received: from n3.nabble.com ([162.255.23.22]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1frf6M-0002De-0C for pgsql-admin@postgresql.org; Mon, 20 Aug 2018 07:59:55 +0000 Received: from n3.nabble.com (localhost [127.0.0.1]) by n3.nabble.com (Postfix) with ESMTP id 28796EA6D4DA for ; Mon, 20 Aug 2018 00:59:49 -0700 (MST) Date: Mon, 20 Aug 2018 00:59:49 -0700 (MST) From: pavan95 To: pgsql-admin@postgresql.org Message-ID: <1534751989163-0.post@n3.nabble.com> In-Reply-To: <11f06cb4-8e48-7090-76e0-438b54c70660@matrix.gatewaynet.com> References: <1534224580242-0.post@n3.nabble.com> <1534746282900-0.post@n3.nabble.com> <1534747341264-0.post@n3.nabble.com> <1534748661624-0.post@n3.nabble.com> <17b9b7a5-5377-b904-0e8a-e72e72efe1ef@matrix.gatewaynet.com> <1534750828102-0.post@n3.nabble.com> <11f06cb4-8e48-7090-76e0-438b54c70660@matrix.gatewaynet.com> Subject: Re: logical Replication MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > Hi Achilleas, > >> Now on the publisher side what does : >> select * from pg_stat_replication ; >> tell you? > Please find the below output: >> *select * from pg_stat_replication ;* > pid | usesysid | usename | application_name | client_addr | > client_hostname | client_port | backend_start | > backend_xmin | state | sent_lsn | write_lsn | flush_lsn | > replay_lsn > | write_lag | flush_lag | replay_lag | sync_priority | sync_state > -------+----------+----------+------------------+--------------+-----------------+-------------+----------------------------------+--------------+-----------+------------+------------+------------+------------+-----------+-----------+------------+---------------+------------ > 32515 | 78225 | user | appn | xxx.xxx.xx.xxx | > | 411111 | 2018-08-20 11:32:09.636622+05:30 | | > streaming > | 0/69BE27D0 | 0/69BE27D0 | 0/69BE27D0 | 0/69BE27D0 | | > | | 0 | async > >>So here you have zero lag. How do you experience the lag? What do you exactly measure? Actually there are no running transactions in the database. When I insert the data suppose 100 records in a table and after commit connect to the subscriber database and issue row count from that particular table, I am finding that the data didn't got replicated. Later which I will proceed with : ALTER SUBSCRIPTION my_sub_name WITH REFRESH PUBLICATION WITH( COPY_DATA) Even then I can't see the data replicated in the subscriber side. Then I will go with dropping and recreating the SUBSCRIPTION on the subscriber side where I will see that inserted 100 records in the subscriber side. Again will try inserting another 1000 records which will get replicated within microsecond(I guess). This is what I will consider as lag. Hope I answered your question. Looking forward to hear from you. Regards, Pavan -- Sent from: http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html