Horton

Thread

Commits

  1. libpq: Fix "servicefile" after fallback to system service file

  2. libpq: Add "servicefile" connection option

  1. SERVICEFILE shows wrong file after servicefile fallback

    Chao Li <li.evan.chao@gmail.com> — 2026-06-02T13:42:23Z

    Hi,

While testing “psql: Add variable SERVICEFILE”, 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=/tmp/svc psql "dbname=postgres service=actual servicefile=/tmp/svc/empty.conf"
psql (19beta1)
Type "help" for help.

postgres=# \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=/tmp/svc psql "dbname=postgres service=actual servicefile=/tmp/svc/empty.conf"
psql (19beta1)
Type "help" for help.

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

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

  2. Re: SERVICEFILE shows wrong file after servicefile fallback

    Michael Paquier <michael@paquier.xyz> — 2026-06-04T04:47:32Z

    On Tue, Jun 02, 2026 at 09:42:23PM +0800, Chao Li wrote:
> While testing “psql: Add variable SERVICEFILE”, 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:

Right, as of the default file in PGSYSCONFDIR.  This qualifies as an
open item for v19.

> 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. 

Yep, it looks like you are right here.  It does not make sense to show
in SERVICEFILE the file that has been skipped in favor of the second
default in PGSYSCONFDIR.  We need to show the latter.  An \echo of 
SERVICEFILE is an interesting way to show your point.  Why not.

Thanks for the report, will fix.
--
Michael

  3. Re: SERVICEFILE shows wrong file after servicefile fallback

    Chao Li <li.evan.chao@gmail.com> — 2026-06-04T05:47:04Z

    
> On Jun 4, 2026, at 12:47, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Tue, Jun 02, 2026 at 09:42:23PM +0800, Chao Li wrote:
>> While testing “psql: Add variable SERVICEFILE”, 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:
> 
> Right, as of the default file in PGSYSCONFDIR.  This qualifies as an
> open item for v19.
> 
>> 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.
> 
> Yep, it looks like you are right here.  It does not make sense to show
> in SERVICEFILE the file that has been skipped in favor of the second
> default in PGSYSCONFDIR.  We need to show the latter.  An \echo of 
> SERVICEFILE is an interesting way to show your point.  Why not.
> 
> Thanks for the report, will fix.
> --
> Michael

Thanks for confirming. I just added it to the Open Item list.

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