Re: [HACKERS] logical replication and statistics - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] logical replication and statistics
Date
Msg-id CAFj8pRA=poSOnEJmquh01J9MVMf01=szB23eTbsHNHbuZ_=6hw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical replication and statistics  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] logical replication and statistics
List pgsql-hackers


2017-09-25 19:23 GMT+02:00 Petr Jelinek <petr.jelinek@2ndquadrant.com>:
On 25/09/17 19:19, Tom Lane wrote:
> Pavel Stehule <pavel.stehule@gmail.com> writes:
>> I had two instances on one server with different port. I am sure, so
>> replication was functional. Only one issue is statistics
>
>> Master:
>
>> CREATE TABLE foo(id int primary key, a int);
>> CREATE PUBLICATION test_pub FOR TABLE foo;
>> INSERT INTO foo VALUES(1, 200);
>
>> slave
>
>> CREATE TABLE foo(id int primary key, a int);
>> CREATE SUBSCRIPTION test_sub CONNECTION 'port=5432' PUBLICATION test_pub;
>
>> That was all
>
> In this example, nothing's been done yet by the actual replication
> apply process, only by the initial table sync.  Maybe that accounts
> for your not seeing stats?
>

The main replication worker should still be running though. The output
of pg_stat_replication should only be empty if there is nothing running.


I did some inserts, updates, ..

I can recheck it - it was done on 10 RC

Pavel

--
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [HACKERS] Built-in plugin for logical decoding output
Next
From: Maksim Milyutin
Date:
Subject: [HACKERS][BUG] Cache invalidation for queries that contains const oftemporary composite type