On 06/07/2017 07:01 PM, Petr Jelinek wrote:
> On 08/06/17 03:50, Josh Berkus wrote:
>> 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?
>>
>
> Plugin knows while the connection exists, but that's the thing, it goes
> through pluggable interface (that can be used by other plugins, without
> publications) so there would have to be some abstracted way for plugins
> to give some extra information for the pg_stat_replication or similar
> view. I am afraid it's bit too late to design something like that in
> PG10 cycle.
OK, consider it a feature request for PG11, then.
--
Josh Berkus
Containers & Databases Oh My!