Hi folks,
One of the speedbumps I hit when setting up HS+SR was naming the user
the slave would connect as for streaming replication. At first I
picked 'replication', which seemed quite natural to me (and I don't
doubt will seem natural to others as well).
When I started up the slave, I got this error:
FATAL: could not connect to the primary server: FATAL: no
pg_hba.conf entry for replication connection from host
"192.168.21.10", user "replication", SSL on
Bzzzt. Wrong. There *was* such an entry in pg_hba.conf. I wasted a
lot of time checking my conf files for typos before I wondered whether
there might be something wrong with using 'replication' as a username.I changed the username to 'streamrep' and it all
startedworking
perfectly.
I understand that 'replication' is a keyword as far as the database
name is concerned, but I was surprised to find that it was treated as
a keyword in the username field also. I had a look in
src/backend/libpq/hba.c, and next_token() appears to be completely
naive about this. 'replication' (along with 'all', 'sameuser',
'samegroup' and 'samerole') is treated as a keyword wherever it
appears, not just in the field where it is relevant. next_token()
appends a newline to the end of the 'replication' username token, and
that's why the entry doesn't match my connection attempt.
I suspect this is going to trip a lot of people up. We could just
document it and tell people that if they want to use 'replication' as
a username, they'd better quote it in pg_hba.conf. But I'd prefer to
actually solve the problem. We could do this by teaching next_token
to be sensitive to which field it is parsing, and limit keyword
detection appropriately. Or, if that's awkward, we could teach
parse_hba_line to ignore keyword markers where the keyword is not
applicable. The more I think about it, the more I incline towards the
latter.
Thoughts?
Cheers,
BJ