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-08-31 19:40:18
Message-ID: 13497.1567280418@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> 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.

After further thought, there's really no reason *not* to do SyncVariables
here; in normal cases it would accomplish nothing, but it won't cost
much compared to all the other overhead of establishing a connection.

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

And here, my inclination is just to do connection_warnings(false) and
call it good. That means you'll get an SSL (resp. GSS) banner if
SSL is active and no banner if it isn't. A user who's not attuned
to what to expect might not realize the significance of not seeing
anything, but this is such a corner case that I'm unconvinced that
it's worth working harder.

However, it does seem like the Windows-code-page warning is useless
to repeat --- AFAICS that state can't change from one connection
to the next. So I'm inclined to fix it to only print that at
startup.

In sum, then, something like the attached. But I'm unsure about
whether to back-patch this. Maybe, in the stable branches, we
should only back-patch addition of SyncVariables()? But it
hardly seems likely that anyone's app could be broken by this ---
connection_warnings() doesn't print anything in noninteractive
cases.

regards, tom lane

Attachment Content-Type Size
fix-psql-reconnection-logic-1.patch text/x-diff 809 bytes

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2019-09-01 04:35:34 Re: BUG #15987: Improve REINDEX of all indexes of a table at once
Previous Message PG Bug reporting form 2019-08-31 19:06:55 BUG #15988: Improve ANALYZE-statement