Thanks Dave for the reply,
Sorry you must think I'm a 24 Carat Moron but since there is no
documentation, this is actually becoming interesting - especially since
thousands of users before me have started-up with pdadmin apparently without
problems. But my thoughts at the moment are as follows...
1. If at the outset I'm simply creating a server (just a name) for my own
use in which to put databases at a later date, then this server has
initially no relationship with any databases anywhere. That comes later !!!
2. So why the password problems ??? Again the question - is a password
mandatory for a "newly created" server. No the password must relate to the
user (in my case "postgres") and not the server.
3. But I am then asked for a HOST. So this "server" can only relate to a
specific machine and a specific user but NOT a specific postmaster (various
versions i.e. various postmasters can run on a single machine at any time so
indicating the HOST is NOT unique ???). AND NONE OF THIS IS IN THE
30 years ago my girlfriend was working at DEC (digital equipment corp.) in
Munich, writing documentation and as an ICT Instructor I worked with her on
various projects. At the time the motto was to write documentation for "den
duemmsten anzunehmenden Benutzer" (translated - the thickest user one could
reasonably assume). DECs documentation was universally acclaimed as being
the "industry best" and they saved themselves a fortune on Telephone
Helpdesk services - there was no email at the time. Of course you can never
defend yourself from users that think that RTFM doesn't apply to them - but
then I don't see myself as that kind of user. On the contrary - being only
of average intelligence I rely on good documentation.
I wonder how much the flow of mailinglist correspondence could be reduced
(thereby reducing the irritation between mailinglist members) if one were to
apply DECs approach to documentation to the open source world. I have
offered my services but no-one has taken me up on the offer. In any case if
all of this were in the documentation. Then I wouldn't be getting on
everyone's nerves - incl. my own.
To come back to your hint...
Because you specified "localhost", pgAdmin is using a tcp/ip connection.
psql probably defaulted to a Unix socket, which is typically setup in
Postgres to use ident authentication by default. If you replace 'localhost'
with the directory containing the Unix socket (typically '/tmp', but it may
be different on Debian), then it too should authenticate using ident.
Alternatively, modify pg_hba.conf to allow "trust" authentication from
localhost, but that's a potential security risk.
I am crrently reading through postgres-8.0-A4.pdf
19. Client - 281
19.1. The pg_hba.conf - 281
19.2. Authentication methods - 285
19.2.1. Trust authentication - 285
19.2.2. Password authentication - 286
19.2.3. Kerberos authentication - 286
19.2.4. Ident-based authentication - 287
184.108.40.206. Ident Authentication over TCP/IP - 287
220.127.116.11. Ident Authentication over Local Sockets - 288
18.104.22.168. Ident Maps - 288
The following paragraph nailed down the problem. On your assumption that the
default was UNIX sockets, I changed the first line from
# Database administrative login by UNIX sockets
local all postgres ident sameuser
local all postgres trust
And the little bugger did what it was supposed to do.
Since the pg_hba.conf records are examined sequentially for each connection
attempt, the order of the records is significant. Typically, earlier records
will have tight connection match parameters and weaker authentication
methods, while later records will have looser match parameters and stronger
authentication methods. For example, one might wish to use trust
Authentication for local TCP/IP connections but require a password for
remote TCP/IP connections. In this case a record specifying trust
authentication for connections from 127.0.0.1 would appear before a record
specifying password authentication for a wider range of allowed client IP
/tmp offers no idication as to where the default connection method is
defined and strangely the pg_ident.conf file is empty
Thanks again Dave
Regards from sunny Uganda
In response to
pgadmin-support by date
|Next:||From: Raymond O'Donnell||Date: 2012-01-19 19:42:12|
|Subject: Re: Connecting to postgresql with pdadmin III -
|Previous:||From: Raymond O'Donnell||Date: 2012-01-19 14:40:01|
|Subject: Re: Connecting to postgresql with pdadmin III|