Re: psql should re-read connection variables after connection reset - Mailing list pgsql-bugs

From Tom Lane
Subject Re: psql should re-read connection variables after connection reset
Date
Msg-id 22335.1559510675@sss.pgh.pa.us
Whole thread Raw
In response to psql should re-read connection variables after connection reset  (Peter Billen <peter.billen@gmail.com>)
Responses Re: psql should re-read connection variables after connection reset
List pgsql-bugs
Peter Billen <peter.billen@gmail.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



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: inconsistent behaviour of json_to_record and friends with embedded json
Next
From: PG Bug reporting form
Date:
Subject: BUG #15831: pgadmin bug: add column and comment failure when you alter table