pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #16936: psql: \c service= not working
2+ messages / 2 participants
[nested] [flat]
Commits from this thread:
2021-03-23 ea80138545 beac4bd65d d75edab42c 4f670c64ef d5a905ed5e c6eac71a88 Fix psql's \connect command some more.
* BUG #16936: psql: \c service= not working
@ 2021-03-22 02:32 PG Bug reporting form <noreply@postgresql.org>
2021-03-23 01:49 ` Re: BUG #16936: psql: \c service= not working Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2021-03-22 02:32 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: pg_bugs@revmaps.no-ip.org
The following bug has been logged on the website:
Bug reference: 16936
Logged by: Jasen Betts
Email address: pg_bugs@revmaps.no-ip.org
PostgreSQL version: 13.2
Operating system: Linux Debian 10.8 on amd64
Description:
The \c metacommand in psql does not anymore use the full information from
pg_service.conf
It's reading the pg_service.conf file but seems to ignore everything but the
dbname=part part of the entry. this bug seems to be new, but is possibly not
in the psql binary itself, as the bug seems to have at-least partially
migrated to older versions of psql too.
The following is a verbatim transcript except for the initial secret
connection string. obviously the service entry for "[j]" is broken on every
line except dbname, yet all those lines are being ignored.
jasen@ryan:~$ psql 'secret-connection-string deleted'
psql (13.2 (Debian 13.2-1.pgdg100+1), server 10.16 (Debian
10.16-1.pgdg90+1))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384,
bits: 256, compression: off)
Type "help" for help.
back2=> \c service=j
psql (13.2 (Debian 13.2-1.pgdg100+1), server 11.10 (Debian
11.10-1.pgdg100+1))
You are now connected to database "jasen" as user "jasen" via socket in
"/var/run/postgresql" at port "5432".
jasen=# \q
jasen@ryan:~$ psql service=j
psql: error: received invalid response to SSL negotiation: H
jasen@ryan:~$ cat .pg_service.conf
[j]
host=example.com
dbname=jasen
user=nobody
password=paternal_gladius
port=80
jasen@ryan:~$
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #16936: psql: \c service= not working
2021-03-22 02:32 BUG #16936: psql: \c service= not working PG Bug reporting form <noreply@postgresql.org>
@ 2021-03-23 01:49 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2021-03-23 01:49 UTC (permalink / raw)
To: pg_bugs@revmaps.no-ip.org; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> The \c metacommand in psql does not anymore use the full information from
> pg_service.conf
> It's reading the pg_service.conf file but seems to ignore everything but the
> dbname=part part of the entry. this bug seems to be new, but is possibly not
> in the psql binary itself, as the bug seems to have at-least partially
> migrated to older versions of psql too.
Hmm, I suppose this has something to do with the fixes for bug #16604 [1].
Those were not supposed to affect the behavior for -reuse-previous=off
cases, which yours should be since there's an "=" in the \c argument.
However, after poking at it for a bit, I have a theory: are the
service-file entries that aren't being honored overridden by variables
from your environment (PGPORT etc)? I think that patch may have
unintentionally changed the relative priority of service file entries
versus other sources of default values.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/16604-933f4b8791227b15%40postgresql.org
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2021-03-23 01:49 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-22 02:32 BUG #16936: psql: \c service= not working PG Bug reporting form <noreply@postgresql.org>
2021-03-23 01:49 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox