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. > P2: If I create a subscription on a table with no primary key, I do not > recieve a warning. There should be a warning, since in most cases such > a subscription will not work. I suggest the text: > > "logical replication target relation "public.fines" has no primary key. > Either create one, or set REPLICA IDENTITY index and set the published > relation to REPLICA IDENTITY FULL." At that point, we don't know what is being published. If only inserts are being published or REPLICA IDENTITY FULL is set, then it will work. We don't want to give warnings about things that might not be true. More guidance on some of the potential failure cases would be good, but it would need more refinement. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, 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
