pgpass file in postresql.auto.conf?

On Fri, Sep 26, 2025 at 8:06 AM Dan Mahoney (Gushi) <postgres@gushi.org>
wrote:

Hey folks,

In the interest of automation, I've set up a pgpass file for my
pg_basebackup between master and standby. This all works, thusly:

pg_basebackup -d
'postgres://repuser@10.1.1.1:5432/foo?sslmode=verify-ca' -F p
--wal-method=stream -P -R -D /var/db/postgres/data17-test3

However, instead of the password getting baked into the pgsql.auto.conf,
the reference to the passfile gets put in, instead:

It's still early in the morning, so I might still be fuzzy-brained, but are
you asking why the repuser password is not hard-coded
into postresql.auto.conf?

# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=repuser passfile=''/var/db/postgres/.pgpass''
channel_binding=prefer host=10.1.1.1 port=5432 sslmode=''verify-ca''
sslnegotiation=postgres sslcompression=0 sslcertmode=allow sslsni=1
ssl_min_protocol_version=TLSv1.2 gssencmode=disable krbsrvname=postgres
gssdelegation=0 target_session_attrs=any load_balance_hosts=disable
dbname=foo'

But it seems postgres won't actually read the passfile.

Sep 26 12:01:27 hostname postgres[42455]: [7-1] 2025-09-26 12:01:27.658
UTC [42455] FATAL: could not connect to the primary server: connection to
server at "10.1.1.1", port 5432 failed: fe_sendauth: no password supplied

Am I doing something wrong here?

*When* do you get that message? And what does "for my
pg_basebackup between master and standby" mean?

I'm loathe to hand-edit the file, because of that warning there.

Why does pg_basebackup put a reference to a file it it won't read it?

Because you have a subtle bug in the .pgpass file. It's case sensitive,
and requires the domain name of that's part of $HOSTNAME.

Is there an alter system command that can be used to properly populate the
password into this file?

Does the .pgpass file work for "regular" connections?

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

On Fri, 2025-09-26 at 12:05 +0000, Dan Mahoney (Gushi) wrote:

In the interest of automation, I've set up a pgpass file for my
pg_basebackup between master and standby. This all works, thusly:

pg_basebackup -d
'postgres://repuser@10.1.1.1:5432/foo?sslmode=verify-ca' -F p
--wal-method=stream -P -R -D /var/db/postgres/data17-test3

However, instead of the password getting baked into the pgsql.auto.conf,
the reference to the passfile gets put in, instead:

# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=repuser passfile=''/var/db/postgres/.pgpass''
channel_binding=prefer host=10.1.1.1 port=5432 sslmode=''verify-ca''
sslnegotiation=postgres sslcompression=0 sslcertmode=allow sslsni=1
ssl_min_protocol_version=TLSv1.2 gssencmode=disable krbsrvname=postgres
gssdelegation=0 target_session_attrs=any load_balance_hosts=disable
dbname=foo'

That happens when "pg_basebackup" used a password file to connect to
the PostgreSQL server.

But it seems postgres won't actually read the passfile.

Oh yes, it will, as long as it has permissions 0600, 0400 or 0700 and
belongs to the database server OS user (commonly "postgres").
It must have worked for the "pg_basebackup", so PostgreSQL assumes it
will also work for replication.

Sep 26 12:01:27 hostname postgres[42455]: [7-1] 2025-09-26 12:01:27.658
UTC [42455] FATAL: could not connect to the primary server: connection to
server at "10.1.1.1", port 5432 failed: fe_sendauth: no password supplied

Am I doing something wrong here?

That is hard to say. You should have run "pg_basebackup" as the
same OS user that starts the standby.

I'm loathe to hand-edit the file, because of that warning there.

Makes sense, although it is OK as long as you don't mess up the file.

Is there an alter system command that can be used to properly populate the
password into this file?

Sure. If the standby server is up and running (even if it cannot connect
to the primary), you can connect and execute

ALTER SYSTEM SET primary_conninfo = 'password=''my secret password''';

Yours,
Laurenz Albe

On Fri, 26 Sep 2025, Laurenz Albe wrote:

On Fri, 2025-09-26 at 12:05 +0000, Dan Mahoney (Gushi) wrote:

In the interest of automation, I've set up a pgpass file for my
pg_basebackup between master and standby. This all works, thusly:

pg_basebackup -d
'postgres://repuser@10.1.1.1:5432/foo?sslmode=verify-ca' -F p
--wal-method=stream -P -R -D /var/db/postgres/data17-test3

However, instead of the password getting baked into the pgsql.auto.conf,
the reference to the passfile gets put in, instead:

# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=repuser passfile=''/var/db/postgres/.pgpass''
channel_binding=prefer host=10.1.1.1 port=5432 sslmode=''verify-ca''
sslnegotiation=postgres sslcompression=0 sslcertmode=allow sslsni=1
ssl_min_protocol_version=TLSv1.2 gssencmode=disable krbsrvname=postgres
gssdelegation=0 target_session_attrs=any load_balance_hosts=disable
dbname=foo'

That happens when "pg_basebackup" used a password file to connect to
the PostgreSQL server.

But it seems postgres won't actually read the passfile.

Oh yes, it will, as long as it has permissions 0600, 0400 or 0700 and
belongs to the database server OS user (commonly "postgres").
It must have worked for the "pg_basebackup", so PostgreSQL assumes it
will also work for replication.

I found the problem.

When I did the basebackup, I used a string like:

postgres://repuser@10.1.1.1:5432/foo?sslmode=verify-ca

And my .pgpass file on the replica reflects this:

#hostname:port:database:username:password
10.1.1.1:5432:foo:repuser:xxxx

(I read *somewhere* that you can use a dummy databasename in the .pgpass
file for replication purposes, but the actual DB is ignored.)

What I missed was that for replication, the database name in .pgpass
*must* be 'replication', for pgpass to pay attention to it.

As in, while everything else about the connection string allowed
pgbasebackup to find that line, that same fake DB name was not baked in to
the primary_conninfo allow postgres to find the same user.

-Dan

--