Re: Danger of automatic connection reset in psql

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Danger of automatic connection reset in psql
Date: 2016-11-07 20:31:25
Message-ID: 1dd3aa0f-d635-1685-b20d-586a947adc0e@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/4/16 4:04 AM, Oleksandr Shulgin wrote:
> The psql process even exits with an error code 2, which might be not
> that expected. We could stop reading the file and reset connection
> afterwards, but this is probably not that easy to achieve (think of
> nested \i calls).

Well, if you stop reading from the file then I don't think more \i's
will matter, no? I'd certainly like to see improvement here, because the
difference in behavior with \i is annoying.

On the bigger question of how to better protect all these cases (cut &
paste, etc), I think the only robust way to do that is for psql to track
intended transaction status itself. With the amount of parsing it's
already doing, maybe that wouldn't be that hard to add. It looks like
this might require extra libpq calls to constantly check in on server
status; I'm a bit surprised that result objects don't include that info.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-07 20:53:42 Re: Let's get rid of SPI_push/SPI_pop
Previous Message Vicky Vergara 2016-11-07 19:34:41 RV: Compilation warning on 9.5