Skip site navigation (1) Skip section navigation (2)

Keywords in pg_hba.conf should be field-specific

From: Brendan Jurd <direvus(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Keywords in pg_hba.conf should be field-specific
Date: 2010-10-09 02:13:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
"", 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

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




pgsql-hackers by date

Next:From: David E. WheelerDate: 2010-10-09 02:23:15
Subject: Re: GIN vs. Partial Indexes
Previous:From: Brendan JurdDate: 2010-10-09 01:04:21
Subject: Docs for archive_cleanup_command are poor

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group