On Wed, Jun 24, 2020 at 1:06 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > On 2020-Jun-24, Stephen Frost wrote: > > Doesn't mean it makes sense or that we should be supporting that. What > > we should have is a way to allow administrators to configure a system > > for exactly what they want to allow, and it doesn't seem like we're > > doing that today and therefore we should fix it. This isn't the only > > area we have that issue in. > > The way to do that, for the case under discussion, is to reject using a > logical replication connection for physical replication commands.
Reading over this discussion, I see basically three arguments: 1. Andres argues that being able to execute physical replication commands from the same connection as SQL queries is useful, and that people may be relying on it, and that we shouldn't break it without need. 2. Fujii Masao argues that the current situation makes it impossible to write a pg_hba.conf rule that disallows all physical replication connections, because people could get around it by using a logical replication connection for physical replication. 3. Various people argue that it's only accidental that physical replication on a replication=database connection ever worked at all, and therefore we ought to block it. I find argument #1 most convincing, #2 less convincing, and #3 least convincing. In my view, the problem with argument #3 is that just because some feature combination was unintentional doesn't mean it's unuseful or unused. As for #2, suppose someone were to propose a design for logical replication that allowed it to take place without a database connection, so that it could be done with just a regular replication connection. Such a feature would create the same problem Fujii Masao mentions here, but it seems inconceivable that we would for that reason reject it; we make decisions about features based on their usefulness, not their knock-on effects on pg_hba.conf rules. We can always add new kinds of access control restrictions if they are needed; that is a better approach than removing features so that the existing pg_hba.conf facilities can be used to accomplish some particular goal. So really I think this turns on #1: is it plausible that people are using this feature, however inadvertent it may be, and is it potentially useful? I don't see that anybody's made an argument against either of those things. Unless someone can do so, I think we shouldn't disable this. That having been said, I think that the fact that you can execute SQL queries in replication=database connections is horrifying. I really hate that feature. I think it's a bad design, and a bad implementation, and a recipe for tons of bugs. But, blocking physical replication commands on such connections isn't going to solve any of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
