On Sun, 4 Jul 2004, Tom Lane wrote:
> Oliver Elphick <olly@lfix.co.uk> writes:
> > On Sun, 2004-07-04 at 20:41, ghaverla@freenet.edmonton.ab.ca wrote:
> >> My guess is it is that -X (disallow reading of a .psqlrc file) is
> >> somehow turning off the reading of any .pgpass file.
>
> > I can't see how that could be.
>
> I don't believe it either --- libpq will always look for a $HOME/.pgpass
> file.
>
> A couple of possibilities that I don't think have been considered yet:
>
> 1. Old libpq? .pgpass is only supported in 7.3 and later. Even if
> your psql is 7.3, I think it might be possible for the dynamic linker
> to bind a 7.2 libpq.so to it, if your ldconfig search path is such
> that the older libpq.so is found first.
Well, I'm as up to date as debian/unstable is. Almost every day I
do the apt-get update/upgrade thing. My libpq.so.3 is from
7.4.3-1 in terms of Debian.
> 2. Bad permissions on .pgpass? libpq will silently ignore a .pgpass
> file it cannot open for reading.. It will not-so-silently ignore
> a .pgpass file that has any group or world permissions. I'm not
> sure if you are capturing stderr from the psql run; if not, it's
> possible the latter case is occurring and we're just not seeing
> the bleat...
Well, the permissions of .pgpass are 600 owned by postgres in
group postgres. The permissions on /var/lib/postgres are 755 with
it owned by postgres, in group postgres.
And the cron script is telling us the user is postgres, so there
should be no problems reading the file.
What's next, modify the call to psql in do.maintenance by putting
it in a strace?
Gord
