Re: psql should re-read connection variables after connection reset

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Billen <peter(dot)billen(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: psql should re-read connection variables after connection reset
Date: 2019-06-02 21:24:35
Message-ID: 22335.1559510675@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Peter Billen <peter(dot)billen(at)gmail(dot)com> writes:
> After a connection reset, psql should re-read the connection variables.
> This was was initially reported by ysch on IRC and confirmed in the code by
> Zr40. All I'm doing here is making sure that it is reported, as per ysch's
> request.

> I quickly verified this as following:

> 1. start 11 instance
> 2. psql into it
> 3. stop 11 instance
> 4. start 10 instance
> 5. in the existing psql session, first trigger a reconnect ('select 1')
> and then '\df', which depends on the server version. I got:

Hm. I'm not entirely convinced that that needs to be a supported
situation. However, it is a bit odd that CheckConnection is willing to
do UnsyncVariables in one code path but not SyncVariables in the other.

I wonder whether we should also do connection_warnings(false) in this
code path. That could be annoyingly chatty on SSL or GSS connections,
though. It's too bad that printSSLInfo and printGSSInfo don't have
any notion like "print only if different from before". More, I can
think of cases where they're not chatty enough: if before you had an
SSL-encrypted connection, and now you don't, that seems like something
you might wish to know about.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-06-03 09:13:15 BUG #15831: pgadmin bug: add column and comment failure when you alter table
Previous Message Tom Lane 2019-06-02 20:14:17 Re: inconsistent behaviour of json_to_record and friends with embedded json