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. > >>> 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. > > Hmmm, yah, I see. Let me explain why this is a UX issue as-is though: > > 1. User forgets to create a PK on the subscriber node. > > 2. User starts a subscription to the tables. > > 3. Subscription is successful. > > 4. First update hits the publisher node. > > 5. Subscription fails and disconnects. > > The user's first thought is going to be a network issue, or a bug, or > some other problem, not a missing PK. Yeah, they can find that > information in the logs, but only if they think to look for it in the > first place, and in some environments (AWS, containers, etc.) logs can > be very hard to access. > > We really need the subscription to fail at step (2), not wait for the > first update to fail. And if it doesn't fail at step 2, then we should > at least give a warning. > Yes, I actually mentioned somewhere at some point that we should call the checks we call during the replication also from the appropriate DDL commands when possible (the information might not be available when the DDL is executed), but never got to actually implementing it. -- 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
