Re: Danger of automatic connection reset in psql

On Thu, Nov 3, 2016 at 12:26 PM, Ashutosh Bapat <
ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:

>
> A couple of doubts/suggestions:
> 1. Should pset.conn_was_reset be set to false, when we make a
> connection in do_connection()? Usually pset.conn_was_reset would be
> initialised with 0 since it's a global variable, so this may not be
> necessary. But as a precaution should we do this?
>

Hi,

Thank you for your comments.

I think this is not necessary since do_connection() is also called from
MainLoop where we clear the flag explicitly. I also don't see a way we
could enter do_connection() with the conn_was_reset flag set to true in the
first place.

It still makes sense to initialize it to false in startup.c, though.

2. Comment below should be updated to reflect the new change
> /* fall out of loop if lexer reached EOL */
> - if (scan_result == PSCAN_INCOMPLETE ||
> + if (pset.conn_was_reset ||
> + scan_result == PSCAN_INCOMPLETE ||
>

Check. See attached v2.

3. What happens when the connection is reset while the source is a
> file say specified by \i in an interactive shell?

In this case pset.cur_cmd_interactive is false (see mainloop.c:66) and we
don't attempt to reset a failed connection:

postgres(p)=# \i 1.sql
psql:1.sql:1: FATAL: terminating connection due to administrator command
psql:1.sql:1: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
psql:1.sql:1: connection to server was lost
$

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

I will still try to see if we can observe blocking status of a read on
stdin and if that might help in protecting from a more complex case with
pasting into terminal.

--
Alex