Re: Notes on testing Postgres 10b1

From: Josh Berkus <josh(at)berkus(dot)org>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(at)2ndquadrant(dot)com>
Subject: Re: Notes on testing Postgres 10b1
Date: 2017-06-08 01:50:54
Message-ID: f4690ea6-2237-53a0-a942-fba11dccd48b@berkus.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/07/2017 06:25 PM, Petr Jelinek wrote:
> On 08/06/17 03:19, Josh Berkus wrote:
>>
>> Peter and Petr:
>>
>> On 06/07/2017 05:24 PM, Peter Eisentraut wrote:
>>> On 6/7/17 01:01, Josh Berkus wrote:
>>>> * Having defaults on the various _workers all devolve from max_workers
>>>> is also great.
>>>
>>> I'm not aware of anything like that happening.
>>>
>>>> P1. On the publishing node, logical replication relies on the *implied*
>>>> correspondence of the application_name and the replication_slot both
>>>> being named the same as the publication in order to associate a
>>>> particular publication with a particular replication connection.
>>>> However, there's absolutely nothing preventing me from also creating a
>>>> binary replication connection by the same name It really seems like we
>>>> need a field in pg_stat_replication or pg_replication_slots which lists
>>>> the publication.
>>>
>>> I'm not quite sure what you are getting at here. The application_name
>>> seen on the publisher side is the subscription name. You can create a
>>> binary replication connection using the same application_name, but
>>> that's already been possible before. But the publications don't care
>>> about any of this.
>>
>> My point is that there is no system view where I can see, on the origin
>> node, what subscribers are subscribing to which publications. You can
>> kinda guess that from pg_stat_replication etc., but it's not dependable
>> information.
>>
>
> That's like wanting the foreign server to show you which foreign tables
> exist on the local server. This is not a tightly coupled system and you
> are able to setup both sides without them being connected to each other
> at the time of setup, so there is no way publisher can know anything.

Why wouldn't the publisher know who's connected once the replication
connection as been made and the subscription has started? Or is it just
a log position, and the publisher really has no idea how many
publications are being consumed?

--
Josh Berkus
Containers & Databases Oh My!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2017-06-08 02:01:07 Re: Notes on testing Postgres 10b1
Previous Message Chapman Flack 2017-06-08 01:42:30 Re: TAP: allow overriding PostgresNode in get_new_node