Re: Enabling replication connections by default in pg_hba.conf

On Sat, Mar 4, 2017 at 9:47 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thursday, March 2, 2017, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>>
>> On 2/3/17 17:47, Michael Paquier wrote:
>> > On Fri, Feb 3, 2017 at 4:59 AM, Simon Riggs <simon(at)2ndquadrant(dot)com>
>> > wrote:
>> >>> It's weirdly inconsistent now. You need a "replication" line in
>> >>> pg_hba.conf to connect for logical decoding, but you can't restrict
>> >>> that
>> >>> to a specific database because the database column in pg_hba.conf is
>> >>> occupied by the "replication" key word.
>> >> Agreed. Change needed.
>> > That sounds really apealling indeed after thinking about its
>> > implications. So we would simply authorize a WAL sender sending
>> > "replication" to connect if the user name matches. That's in short
>> > check_db() in hba.c.
>>
>> In
>>
>> <https://www.postgresql.org/message-id/7a33990f-75b1-5a4f-e7c0-223e15b84c11@2ndquadrant.com>
>> patch 0006 it is proposed to no longer use the "replication" keyword in
>> pg_hba.conf for logical
>> replication and use the normal database entries instead.
>>
>> However, I don't think we can reasonably get rid of the replication
>> keyword for physical replication. Say if you have a pg_hba.conf like
>>
>> host db1 someusers ...
>> host db2 someusers ...
>> host db3 someusers ...
>>
>> how would you decide access for physical replication? Since physical
>> replication is not to a database, you need a way to call it out
>> separately if your pg_hba.conf style is to enumerate databases.
>
> That's the reason we created the "replication" keyword in the first place,
> isn't it? I think it makes sense to keep that, but it also makes sense to
> not use it for logical.

Yeah, it looks sensible to me to keep "replication" for physical
replication, and switch logical replication checks to match a database
name in hba comparisons.
--
Michael