Re: Handling psql lost connections - Mailing list pgsql-general

From Peter J. Holzer
Subject Re: Handling psql lost connections
Date
Msg-id 20170330142341.GC4612@hjp.at
Whole thread Raw
In response to Handling psql lost connections  (Steve Crawford <scrawford@pinpointresearch.com>)
List pgsql-general
On 2017-03-29 08:49:57 -0700, Steve Crawford wrote:
> When firewalls/VPNs stand between my psql client and a remote PostgreSQL server
> the connection will on occasion time out and drop. This results in the
> following scenario:
>
> -Leave for lunch mid project - leave psql open.
>
> -Return from lunch, complete and submit large query.
>
> -Notice query is taking too long. cancel it.
>
> -Cancel doesn't return - realize that connection has dropped.
>
> -Kill psql - history is not written out. Start query from scratch.
>
> Is there:
[...]
> Yes, I know I and my coworkers could spend brain cycles trying to unerringly
> remember to close and restart connections, write all queries in an external
> editor and then submit them, etc. but I'm looking for more user friendly
> options.

One workaround could be to login to the server, start a screen session
and psql in the screen session. Then if your network connection drops
you can simply login again and resume the screen session. Of course this
only works if you have a shell login on the server which may not be the
case.

        hp

--
   _  | Peter J. Holzer    | A coding theorist is someone who doesn't
|_|_) |                    | think Alice is crazy.
| |   | hjp@hjp.at         | -- John Gordon
__/   | http://www.hjp.at/ |    http://downlode.org/Etext/alicebob.html

Attachment

pgsql-general by date:

Previous
From: "Peter J. Holzer"
Date:
Subject: Re: inevitability of to_date() when convertingrepresentations which don't represent whole timestamps
Next
From: "David G. Johnston"
Date:
Subject: Re: inevitability of to_date() when converting representations whichdon't represent whole timestamps