From: Chao Li <li.evan.chao@gmail.com>
Content-Type: multipart/mixed;
	boundary="Apple-Mail=_67C09965-9E5F-4E78-B184-1B2589E9E79D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: SERVICEFILE shows wrong file after servicefile fallback
Message-Id: <59DD1652-4EB5-449B-8DE3-959F06561A96@gmail.com>
Date: Tue, 2 Jun 2026 21:42:23 +0800
Cc: Michael Paquier <michael.paquier@gmail.com>,
 tfoertsch123@gmail.com,
 kanbayashi.dev@gmail.com
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/59DD1652-4EB5-449B-8DE3-959F06561A96%40gmail.com>
Precedence: bulk


--Apple-Mail=_67C09965-9E5F-4E78-B184-1B2589E9E79D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

While testing =E2=80=9Cpsql: Add variable SERVICEFILE=E2=80=9D, I found =
a small issue where SERVICEFILE may show the wrong value.

While tracing the code, I noticed there is a fallback path. If the =
service file specified in the connection string does not contain the =
requested service, libpq falls back to pg_service.conf. So I tested the =
following case:

1. Prepare two service files: one empty, and the other containing the =
service:
```
% mkdir -p /tmp/svc
% : > /tmp/svc/empty.conf
% printf '[actual]\n' > /tmp/svc/pg_service.conf
```

2. Run psql with a connection string and show SERVICEFILE:
```
% PGSYSCONFDIR=3D/tmp/svc psql "dbname=3Dpostgres service=3Dactual =
servicefile=3D/tmp/svc/empty.conf"
psql (19beta1)
Type "help" for help.

postgres=3D# \echo :SERVICE :SERVICEFILE
actual /tmp/svc/empty.conf
```

Here, SERVICEFILE shows the empty file /tmp/svc/empty.conf, which is =
wrong because the actual service is read from /tmp/svc/pg_service.conf.

I think the bug was actually introduced by the previous commit =
092f3c63efc6. In parseServiceFile(), if the service file has already =
been set in the connection options, it refuses to update the value, so =
the fallback service file is not synced to the connection options. Then =
SERVICEFILE is read from the connection options, which still contain the =
original file specified on the command line. So, SERVICEFILE just makes =
the bug visible.

The fix is simple, when fallback happens, explicitly store the actual =
service file into the connection options. See the attached patch for =
details.

With the fix, SERVICEFILE shows the actual service file:
```
% PGSYSCONFDIR=3D/tmp/svc psql "dbname=3Dpostgres service=3Dactual =
servicefile=3D/tmp/svc/empty.conf"
psql (19beta1)
Type "help" for help.

postgres=3D# \echo :SERVICE :SERVICEFILE
actual /tmp/svc/pg_service.conf
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/


--Apple-Mail=_67C09965-9E5F-4E78-B184-1B2589E9E79D
Content-Disposition: attachment;
	filename=v1-0001-libpq-Report-correct-service-file-after-fallback.patch
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	name="v1-0001-libpq-Report-correct-service-file-after-fallback.patch"
Content-Transfer-Encoding: quoted-printable

=46rom=202133f5ea986f057486d5d9cab11a19b0d1d099de=20Mon=20Sep=2017=20=
00:00:00=202001=0AFrom:=20"Chao=20Li=20(Evan)"=20<lic@highgo.com>=0A=
Date:=20Tue,=202=20Jun=202026=2016:50:44=20+0800=0ASubject:=20[PATCH=20=
v1]=20libpq:=20Report=20correct=20service=20file=20after=20fallback=0A=0A=
When=20an=20explicitly=20specified=20service=20file=20does=20not=20=
contain=20the=20requested=0Aservice,=20libpq=20falls=20back=20to=20the=20=
system-wide=20pg_service.conf=20file.=20=20If=20the=0Aservice=20is=20=
found=20there,=20however,=20the=20"servicefile"=20connection=20option=20=
still=0Areported=20the=20explicitly=20specified=20file.=0A=0AUpdate=20=
the=20option=20after=20a=20successful=20fallback=20so=20that=20=
PQconninfo()=20and=0Apsql's=20SERVICEFILE=20variable=20report=20the=20=
file=20that=20supplied=20the=20service.=0AAdd=20a=20TAP=20test=20for=20=
this=20case.=0A=0AAuthor:=20Chao=20Li=20<lic@highgo.com>=0A---=0A=20=
src/interfaces/libpq/fe-connect.c=20=20=20=20=20|=205=20+++++=0A=20=
src/interfaces/libpq/t/006_service.pl=20|=208=20++++++++=0A=202=20files=20=
changed,=2013=20insertions(+)=0A=0Adiff=20--git=20=
a/src/interfaces/libpq/fe-connect.c=20=
b/src/interfaces/libpq/fe-connect.c=0Aindex=204272d386e64..d6d5ad14c6a=20=
100644=0A---=20a/src/interfaces/libpq/fe-connect.c=0A+++=20=
b/src/interfaces/libpq/fe-connect.c=0A@@=20-6049,6=20+6049,11=20@@=20=
next_file:=0A=20=09status=20=3D=20parseServiceFile(serviceFile,=20=
service,=20options,=20errorMessage,=20&group_found);=0A=20=09if=20=
(status=20!=3D=200)=0A=20=09=09return=20status;=0A+=09/*=20Update=20=
servicefile=20to=20the=20file=20that=20actually=20supplied=20the=20=
service=20*/=0A+=09if=20(group_found=20&&=20service_fname=20!=3D=20NULL=20=
&&=0A+=09=09conninfo_storeval(options,=20"servicefile",=20serviceFile,=0A=
+=09=09=09=09=09=09=20=20errorMessage,=20false,=20false)=20=3D=3D=20=
NULL)=0A+=09=09return=203;=0A=20=0A=20last_file:=0A=20=09if=20=
(!group_found)=0Adiff=20--git=20a/src/interfaces/libpq/t/006_service.pl=20=
b/src/interfaces/libpq/t/006_service.pl=0Aindex=20=
7462d21314d..144248b8533=20100644=0A---=20=
a/src/interfaces/libpq/t/006_service.pl=0A+++=20=
b/src/interfaces/libpq/t/006_service.pl=0A@@=20-143,6=20+143,14=20@@=20=
local=20$ENV{PGSERVICEFILE}=20=3D=20"$srvfile_empty";=0A=20=09=09sql=20=
=3D>=20"SELECT=20'connect2_3'",=0A=20=09=09expected_stdout=20=3D>=20=
qr/connect2_3/);=0A=20=0A+=09my=20$srvfile_empty_win_cared=20=3D=20=
$srvfile_empty;=0A+=09$srvfile_empty_win_cared=20=3D~=20s/\\/\\\\/g;=0A+=09=
$dummy_node->connect_ok(=0A+=09=09q{service=3Dmy_srv=20servicefile=3D'}=20=
.=20$srvfile_empty_win_cared=20.=20q{'},=0A+=09=09'servicefile=20option=20=
is=20updated=20when=20service=20is=20found=20in=20default=20=
pg_service.conf',=0A+=09=09sql=20=3D>=20'\echo=20:SERVICEFILE',=0A+=09=09=
expected_stdout=20=3D>=20qr/^\Q$srvfile_default\E$/);=0A+=0A=20=09local=20=
$ENV{PGSERVICE}=20=3D=20'undefined-service';=0A=20=09=
$dummy_node->connect_fails(=0A=20=09=09'',=0A--=20=0A2.50.1=20(Apple=20=
Git-155)=0A=0A=

--Apple-Mail=_67C09965-9E5F-4E78-B184-1B2589E9E79D--