sudo systemctl stop postgresql
sudo systemctl start postgresql
pg_ctl reload -D /etc/postgresql/11/main/(I know that I could've used "systemctl restart ".) Like I said elsewhere, the "reload" seems to be superfluous. But it costs nothing to do it.
Actually, you only needed the reload, you don't need to restart postgres for changes to pg_hba.conf.
Then I did "su bob" and first did this sanity test:psql -h localhost -p 5432 -d postgres -U aliceThat worked fine—and "select current_role" showed "alice".Then I did the spelling for "peer", to authorize explicitly as "bob":psql -d postgres -U bobThat worked too so that "select current_role" now showed "bob". Finally, I omitted "bob" here in the belief that this would make my mapping kick in and authorize using the cluster role "alice":psql -d postgresIt got me in without error. (And, as hoped for, there was no password challenge.) But "select current_role" showed that the mapping had been ignored and that I was connected again as "bob".What am I doing wrong?
I think maybe you are considering psql and the postgres cluster to be more tightly integrated than they actually are. The psql process does not know anything about your pg_hba.conf or your identity map.
Remember that if you don't specify a username for psql, psql (not postgres!) will default to using your system user. So, if you are the user bob, these two commands are equivalent:
psql -d postgres -U bob
psql -d postgres
You can read more about the connection negotiation here:
Importantly, the frontend (psql in this case) sends both the username and the database name as part of the first message, so it has to figure out what username and db name to use before initiating any communication with the database.
-Jeremy
