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.