Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should

>
>
>

> *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 alice*
>
> That worked fine—and "select current_role" showed "alice".
>
> Then I did the spelling for "peer", to authorize explicitly as "bob":
>
>
> *psql -d postgres -U bob*
> That 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 postgres*
>
> It 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:
https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.6.7.3

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