Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3ZZN-000aeS-Lo for pgsql-general@arkaria.postgresql.org; Tue, 30 Sep 2025 12:35:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v3ZZL-009VPK-Hr for pgsql-general@arkaria.postgresql.org; Tue, 30 Sep 2025 12:35:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v3ZZK-009VPB-TS for pgsql-general@lists.postgresql.org; Tue, 30 Sep 2025 12:34:59 +0000 Received: from prime.gushi.org ([2620:137:6000:10::142]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v3ZZH-000tlZ-1I for pgsql-general@lists.postgresql.org; Tue, 30 Sep 2025 12:34:58 +0000 Received: from prime.gushi.org (localhost [127.0.0.1]) by prime.gushi.org (8.18.1/8.18.1) with ESMTPS id 58UCYj3B057624 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 30 Sep 2025 12:34:45 GMT (envelope-from danm@prime.gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 58UCYj3B057624 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1759235685; bh=JHUUlVFt3mf0dncYFFqIKh99kmz1YMu8UA78SYLO/Qg=; h=Date:From:To:cc:Subject:In-Reply-To:References; z=Date:=20Tue,=2030=20Sep=202025=2012:34:43=20+0000=20(UTC)|From:=2 0"Dan=20Mahoney=20(Gushi)"=20|To:=20Laurenz=20 Albe=20|cc:=20pgsql-general@lists.postgr esql.org|Subject:=20Re:=20pgpass=20file=20in=20postresql.auto.conf ?|In-Reply-To:=20<89f3ec586ade0b6fec211ea22d45fb32500611ff.camel@c ybertec.at>|References:=20<31ded2b6-d8f8-497c-59ea-c7885b4a7d26@gu shi.org>=20<89f3ec586ade0b6fec211ea22d45fb32500611ff.camel@cyberte c.at>; b=Dyjm+jQBBjcovQsb/GcRlPsa2Gr9wx5E8qeAubDJEBnpBrzllGclA4oNiUswOEuqF xJ00zR7FhBo+AhDB6uwlGtQaZMoXYpG9fbaBXoO+beSWfMMtkdJTpyq72zZMv+LPuk Oa9aR6NbxnyZKpeHuLDazNkQslt88xp+5Zycs35eUE0k9Dym+OfGYRoYOUDk4PAc2w qN3sua0VMJlzN/lYVUTi1sNb5yGmQyMXyvWtLMsyGhg7Og0FNWlUtNOhiWYBkWRZZD VEMCQ53KivzqLtWzAIOG9KmxrRkSnUwv3sNcV3ELSTK8P81zCJmk225q7UnXSCZ0+c aASJ8Fgokairg== Received: (from danm@localhost) by prime.gushi.org (8.18.1/8.18.1/Submit) id 58UCYi4K057621; Tue, 30 Sep 2025 12:34:44 GMT (envelope-from danm) Date: Tue, 30 Sep 2025 12:34:43 +0000 (UTC) From: "Dan Mahoney (Gushi)" To: Laurenz Albe cc: pgsql-general@lists.postgresql.org Subject: Re: pgpass file in postresql.auto.conf? In-Reply-To: <89f3ec586ade0b6fec211ea22d45fb32500611ff.camel@cybertec.at> Message-ID: References: <31ded2b6-d8f8-497c-59ea-c7885b4a7d26@gushi.org> <89f3ec586ade0b6fec211ea22d45fb32500611ff.camel@cybertec.at> X-OpenPGP-Key-ID: 0x624BB249 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (prime.gushi.org [0.0.0.0]); Tue, 30 Sep 2025 12:34:45 +0000 (UTC) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 --