Re: Danger of automatic connection reset in psql

From: Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Danger of automatic connection reset in psql
Date: 2016-11-21 09:55:24
Message-ID: CACACo5QtpP++38PYaE2o_-EzPELkcGYVrHLsPhOg83On0A-JWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

> On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
>
>> Automatic connection reset is a nice feature for server development,
>> IMO. Is it really useful for anything else is a good question.
>>
>
> I use it all the time for application development; my rebuild script will
> forcibly kick everyone out to re-create the database. I put that in because
> I invariably end up with a random psql sitting somewhere that I don't want
> to track down.
>
> What currently stinks though is if the connection is dead and the next
> command I run is a \i, psql just dies instead of re-connecting. It'd be
> nice if before reading the script it checked connection status and
> attempted a reconnect.
>
> At least an option to control that behavior seems like a good idea,
>> maybe even set it to 'no reconnect' by default, so that people who
>> really use it can make conscious choice about enabling it in their
>> .psqlrc or elsewhere.
>>
>
> +1, I don't think it needs to be the default.

So if we go in this direction, should the option be specified from command
line or available via psqlrc (or both?) I think both make sense.

What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect in non-interactive
mode? I have no use case for that, but it might be different for others.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on / off /
interactive (the last one being the default).

In any case it would make sense to rectify the difference in current
behavior when the failing command is \i somefile.sql. It would be
appropriate to stop parsing the file and reset the connection.

Other thoughts?

--
Alex

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2016-11-21 09:58:18 Re: Mail thread references in commits
Previous Message Craig Ringer 2016-11-21 09:49:01 Re: delta relations in AFTER triggers