Re: psql swallowed my "BEGIN;" on reset... user beware? - Mailing list pgsql-general

From Ryan Kelly
Subject Re: psql swallowed my "BEGIN;" on reset... user beware?
Date
Msg-id 20130930161537.GA16574@llserver.lakeliving.com
Whole thread Raw
In response to Re: psql swallowed my "BEGIN;" on reset... user beware?  (Moshe Jacobson <moshe@neadwerx.com>)
List pgsql-general
On Mon, Sep 09/30/13, 2013 at 11:49:29AM -0400, Moshe Jacobson wrote:
> On Sun, Sep 29, 2013 at 2:18 AM, Ken Tanzer <ken.tanzer@gmail.com> wrote:
>
> > After restarting the server in another window, I was surprised that my
> > command did not run in a transaction:
> >
> > spc_test_scratch=# BEGIN; DROP VIEW IF EXISTS ptest_mip ; DROP VIEW
> > rent_info; \i create.view.rent_info.sql
> > FATAL:  terminating connection due to administrator command
> > server closed the connection unexpectedly
> >         This probably means the server terminated abnormally
> >         before or while processing the request.
> > The connection to the server was lost. Attempting reset: Succeeded.
> > NOTICE:  view "ptest_mip" does not exist, skipping
> > DROP VIEW
> > DROP VIEW
> > CREATE VIEW
> > spc_test_scratch=# commit;
> > WARNING:  there is no transaction in progress
> > COMMIT
> >
>
> This seems like a pretty serious issue. My opinion is that psql should
> refuse to execute further commands on a line of input if any of them fails
> due to a terminated connection.

FWIW, I often have this same problem. I also agree with the proposed
solution.

The current code seems to have the connection reset logic down inside
the result processing routines. It looks like it would be relatively
straightforward to add two calls to ConnectionUp in ProcessResult and
ProcessResult to resolve this. But it would be a change in behavior.

-Ryan


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: psql swallowed my "BEGIN;" on reset... user beware?
Next
From: Ryan Kelly
Date:
Subject: Re: psql swallowed my "BEGIN;" on reset... user beware?