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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers