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 started working 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
