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. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
