Danger of automatic connection reset in psql
Hi Hackers!
When using psql interactively one might be tempted to guard potentially
destructive commands such as "UPDATE / DELETE / DROP <object>" by starting
the input line with an explicit "BEGIN; ...". This has the added benefit
that then you invoke the command by reverse-searching the command history,
you get it together with the guarding transaction open statement.
This, however, is not 100% safe as I've found out a few days ago. Should
the connection to the server get lost, the first of semicolon-separated
statements, "BEGIN;" will only trigger connection reset, and if that is
successful the following command(s) are going to be executed on the newly
opened connection, but without the transaction guard.
I'm not the first one to discover that, a search in archives gives at least
3 results:
/messages/by-id/1097174870.9273.8.camel@ipso.snappymail.ca
/messages/by-id/4BF6A496.2090106@comgate.c
/messages/by-id/CAD3a31U+fSBsq=txw2G-D+fPND_UN-nSojrGyaD+hkYUzvxusQ@mail.gmail.com
The second one even resulted in a TODO item:
Prevent psql from sending remaining single-line multi-statement queries
after reconnection
I was thinking that simply adding a bool flag in the pset struct, to
indicate that connection was reset during attempt to execute the last query
would do the trick, but it only helps in exactly the case described above.
Since this is already an improvement, I'm attaching a patch.
If on the other hand, someone is pasting into psql's terminal a block of
commands enclosed in BEGIN/COMMIT, the same bug is triggered: BEGIN doesn't
have effect and the rest of commands run outside of transaction.
Is it possible at all to protect against the latter case? How?
--
Alex
Attachments:
0001-psql-stop-sending-commands-after-connection-reset.patchtext/x-patch; charset=US-ASCII; name=0001-psql-stop-sending-commands-after-connection-reset.patchDownload
From 3eae5e5d91084e0882a286bac464782701e17d21 Mon Sep 17 00:00:00 2001
From: Oleksandr Shulgin <oleksandr.shulgin@zalando.de>
Date: Thu, 20 Oct 2016 12:24:48 +0200
Subject: [PATCH] psql: stop sending commands after connection reset
Previsouly an input line such as "BEGIN; UPDATE something..." could
result in UPDATE running outside of transaction if the first statement
happen to trigger connection reset.
NB: this does *not* protect from blocks of commands pasted into the
terminal.
---
src/bin/psql/common.c | 2 ++
src/bin/psql/mainloop.c | 5 ++++-
src/bin/psql/settings.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index a7789df..34a4507 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -386,6 +386,8 @@ CheckConnection(void)
}
else
psql_error("Succeeded.\n");
+
+ pset.conn_was_reset = true;
}
return OK;
diff --git a/src/bin/psql/mainloop.c b/src/bin/psql/mainloop.c
index 37dfa4d..6d39ce8 100644
--- a/src/bin/psql/mainloop.c
+++ b/src/bin/psql/mainloop.c
@@ -391,11 +391,14 @@ MainLoop(FILE *source)
}
/* fall out of loop if lexer reached EOL */
- if (scan_result == PSCAN_INCOMPLETE ||
+ if (pset.conn_was_reset ||
+ scan_result == PSCAN_INCOMPLETE ||
scan_result == PSCAN_EOL)
break;
}
+ pset.conn_was_reset = false;
+
/* Add line to pending history if we didn't execute anything yet */
if (pset.cur_cmd_interactive && !line_saved_in_history)
pg_append_history(line, history_buf);
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
index 8cfe9d2..39a4be0 100644
--- a/src/bin/psql/settings.h
+++ b/src/bin/psql/settings.h
@@ -102,6 +102,9 @@ typedef struct _psqlSettings
FILE *cur_cmd_source; /* describe the status of the current main
* loop */
bool cur_cmd_interactive;
+ bool conn_was_reset; /* indicates that the connection was reset
+ * during the last attempt to execute an
+ * interactive command */
int sversion; /* backend server version */
const char *progname; /* in case you renamed psql */
char *inputfile; /* file being currently processed, if any */
--
2.7.4
On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin <
oleksandr.shulgin@zalando.de> wrote:
I'm not the first one to discover that, a search in archives gives at
least 3 results:
/messages/by-id/1097174870.9273.8.camel@ipso.snappymail.ca
Sorry that one got broken, should be:
On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin <
oleksandr.shulgin@zalando.de> wrote:
Since this is already an improvement, I'm attaching a patch.
If on the other hand, someone is pasting into psql's terminal a block of
commands enclosed in BEGIN/COMMIT, the same bug is triggered: BEGIN doesn't
have effect and the rest of commands run outside of transaction.Is it possible at all to protect against the latter case? How?
One idea I was just suggested is to make interactive psql sessions buffer
in all available input, before it's going to block. This way it doesn't
matter if the multiple statements are appearing on one line or are being
pasted.
Feasible?
--
Alex
On Thu, Oct 20, 2016 at 5:25 PM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:
On Thu, Oct 20, 2016 at 12:28 PM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:Since this is already an improvement, I'm attaching a patch.
If on the other hand, someone is pasting into psql's terminal a block of
commands enclosed in BEGIN/COMMIT, the same bug is triggered: BEGIN doesn't
have effect and the rest of commands run outside of transaction.Is it possible at all to protect against the latter case? How?
One idea I was just suggested is to make interactive psql sessions buffer in
all available input, before it's going to block. This way it doesn't matter
if the multiple statements are appearing on one line or are being pasted.Feasible?
psql seems to be reading one line (or upto EOF) at a time. If it finds
a ';' in the fetched input, it sends the query to the server and
fetches the result. That's when it will notice a server crash. The
next time it will try to fetch the line, I doubt if psql has any way
to tell, whether the block of commands was pasted all at a time or
entered one at a time.y It's same thing for psql and really I guess
it's the same thing for any interactive program. I guess, all the
pasted result is not in psql's buffers if it spans multiple lines and
has ';' in-between. So, I don't think, it's feasible to protect
against that one.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Oct 20, 2016 at 3:58 PM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:
Hi Hackers!
When using psql interactively one might be tempted to guard potentially
destructive commands such as "UPDATE / DELETE / DROP <object>" by starting
the input line with an explicit "BEGIN; ...". This has the added benefit
that then you invoke the command by reverse-searching the command history,
you get it together with the guarding transaction open statement.This, however, is not 100% safe as I've found out a few days ago. Should
the connection to the server get lost, the first of semicolon-separated
statements, "BEGIN;" will only trigger connection reset, and if that is
successful the following command(s) are going to be executed on the newly
opened connection, but without the transaction guard.I'm not the first one to discover that, a search in archives gives at least
3 results:/messages/by-id/1097174870.9273.8.camel@ipso.snappymail.ca
/messages/by-id/4BF6A496.2090106@comgate.c
/messages/by-id/CAD3a31U+fSBsq=txw2G-D+fPND_UN-nSojrGyaD+hkYUzvxusQ@mail.gmail.comThe second one even resulted in a TODO item:
Prevent psql from sending remaining single-line multi-statement queries
after reconnectionI was thinking that simply adding a bool flag in the pset struct, to
indicate that connection was reset during attempt to execute the last query
would do the trick, but it only helps in exactly the case described above.Since this is already an improvement, I'm attaching a patch.
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?
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 ||3. What happens when the connection is reset while the source is a
file say specified by \i in an interactive shell?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Nov 3, 2016 at 12:26 PM, Ashutosh Bapat <
ashutosh.bapat@enterprisedb.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
Attachments:
psql-stop-after-reset-v2.patchtext/x-patch; charset=US-ASCII; name=psql-stop-after-reset-v2.patchDownload
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
new file mode 100644
index a7789df..34a4507
*** a/src/bin/psql/common.c
--- b/src/bin/psql/common.c
*************** CheckConnection(void)
*** 386,391 ****
--- 386,393 ----
}
else
psql_error("Succeeded.\n");
+
+ pset.conn_was_reset = true;
}
return OK;
diff --git a/src/bin/psql/mainloop.c b/src/bin/psql/mainloop.c
new file mode 100644
index 37dfa4d..c049a39
*** a/src/bin/psql/mainloop.c
--- b/src/bin/psql/mainloop.c
*************** MainLoop(FILE *source)
*** 390,401 ****
break;
}
! /* fall out of loop if lexer reached EOL */
if (scan_result == PSCAN_INCOMPLETE ||
! scan_result == PSCAN_EOL)
break;
}
/* Add line to pending history if we didn't execute anything yet */
if (pset.cur_cmd_interactive && !line_saved_in_history)
pg_append_history(line, history_buf);
--- 390,404 ----
break;
}
! /* fall out of loop if lexer reached EOL or connection was reset */
if (scan_result == PSCAN_INCOMPLETE ||
! scan_result == PSCAN_EOL ||
! pset.conn_was_reset)
break;
}
+ pset.conn_was_reset = false;
+
/* Add line to pending history if we didn't execute anything yet */
if (pset.cur_cmd_interactive && !line_saved_in_history)
pg_append_history(line, history_buf);
diff --git a/src/bin/psql/settings.h b/src/bin/psql/settings.h
new file mode 100644
index 8cfe9d2..39a4be0
*** a/src/bin/psql/settings.h
--- b/src/bin/psql/settings.h
*************** typedef struct _psqlSettings
*** 102,107 ****
--- 102,110 ----
FILE *cur_cmd_source; /* describe the status of the current main
* loop */
bool cur_cmd_interactive;
+ bool conn_was_reset; /* indicates that the connection was reset
+ * during the last attempt to execute an
+ * interactive command */
int sversion; /* backend server version */
const char *progname; /* in case you renamed psql */
char *inputfile; /* file being currently processed, if any */
diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c
new file mode 100644
index 7ce05fb..e238de9
*** a/src/bin/psql/startup.c
--- b/src/bin/psql/startup.c
*************** main(int argc, char *argv[])
*** 139,144 ****
--- 139,145 ----
pset.last_error_result = NULL;
pset.cur_cmd_source = stdin;
pset.cur_cmd_interactive = false;
+ pset.conn_was_reset = false;
/* We rely on unmentioned fields of pset.popt to start out 0/false/NULL */
pset.popt.topt.format = PRINT_ALIGNED;
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 7, 2016 at 9:31 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
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.
What I mean is you need a longjump out of the innermost \i back to the
toplevel interactive prompt. This might be not a problem since this is
what already happens upon receiving SIGINT, I believe.
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.
This doesn't have to be solely about transaction status, though for
something immediately destructive such as DELETE or UPDATE one should
expect a transaction guard. But for example, pasting something like the
following two lines
SET search_path = 'fancy_new_schema', 'old_boring_schema', public;
SELECT * FROM get_item_ids_to_delete(...);
can give slightly different results depending on whether the first
statement had it effect or not. And since psql is trying to be very
helpful here by resetting the connection, it makes it all too easy to
overlook the problem.
What do you think about trying to read everything we can from the terminal
using non-blocking IO and only if that gives EWOULDBLOCK, starting the
interactive prompt?
--
Alex
On Tue, Nov 8, 2016 at 9:53 AM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:
On Mon, Nov 7, 2016 at 9:31 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
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.What I mean is you need a longjump out of the innermost \i back to the
toplevel interactive prompt. This might be not a problem since this is what
already happens upon receiving SIGINT, I believe.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.This doesn't have to be solely about transaction status, though for
something immediately destructive such as DELETE or UPDATE one should expect
a transaction guard. But for example, pasting something like the following
two linesSET search_path = 'fancy_new_schema', 'old_boring_schema', public;
SELECT * FROM get_item_ids_to_delete(...);can give slightly different results depending on whether the first statement
had it effect or not. And since psql is trying to be very helpful here by
resetting the connection, it makes it all too easy to overlook the problem.What do you think about trying to read everything we can from the terminal
using non-blocking IO and only if that gives EWOULDBLOCK, starting the
interactive prompt?
I think that's unlikely to be completely reliable.
How about, instead of all this, adding an option to psql to suppress
the automatic reconnect behavior? When enabled, psql just exits
instead of trying to reconnect.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
How about, instead of all this, adding an option to psql to suppress
the automatic reconnect behavior? When enabled, psql just exits
instead of trying to reconnect.
+1. But, existing users may not notice addition of the new option and
still continue to face problem. If we add the option and make it
default not to reconnect, they will notice it and use option to get
older behaviour, but that will break applications relying on the
current behaviour. Either way, users will have at least something to
control the connection reset.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2016-11-11 5:14 GMT+01:00 Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>:
How about, instead of all this, adding an option to psql to suppress
the automatic reconnect behavior? When enabled, psql just exits
instead of trying to reconnect.+1. But, existing users may not notice addition of the new option and
still continue to face problem. If we add the option and make it
default not to reconnect, they will notice it and use option to get
older behaviour, but that will break applications relying on the
current behaviour. Either way, users will have at least something to
control the connection reset.
The reconnect in not interactive mode is a bad idea - and there should be
disabled everywhere (it cannot to break any application - the behave of
script when a server is restarted must be undefined (100% if ON_ERROR_STOP
is active). In interactive mode it can be controlled by some psql session
variables like AUTOCOMMIT.
Regards
Pavel
Show quoted text
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Nov 11, 2016 at 5:37 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:
2016-11-11 5:14 GMT+01:00 Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
:How about, instead of all this, adding an option to psql to suppress
the automatic reconnect behavior? When enabled, psql just exits
instead of trying to reconnect.+1. But, existing users may not notice addition of the new option and
still continue to face problem. If we add the option and make it
default not to reconnect, they will notice it and use option to get
older behaviour, but that will break applications relying on the
current behaviour. Either way, users will have at least something to
control the connection reset.The reconnect in not interactive mode is a bad idea - and there should be
disabled everywhere (it cannot to break any application - the behave of
script when a server is restarted must be undefined (100% if ON_ERROR_STOP
is active). In interactive mode it can be controlled by some psql session
variables like AUTOCOMMIT.
Yes, I've never suggested it should affect non-interactive mode.
Automatic connection reset is a nice feature for server development, IMO.
Is it really useful for anything else is a good question.
At least an option to control that behavior seems like a good idea, maybe
even set it to 'no reconnect' by default, so that people who really use it
can make conscious choice about enabling it in their .psqlrc or elsewhere.
--
Alex
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.
I use it all the time for application development; my rebuild script
will forcibly kick everyone out to re-create the database. I put that in
because I invariably end up with a random psql sitting somewhere that I
don't want to track down.
What currently stinks though is if the connection is dead and the next
command I run is a \i, psql just dies instead of re-connecting. It'd be
nice if before reading the script it checked connection status and
attempted a reconnect.
At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.
+1, I don't think it needs to be the default.
--
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--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.I use it all the time for application development; my rebuild script will
forcibly kick everyone out to re-create the database. I put that in because
I invariably end up with a random psql sitting somewhere that I don't want
to track down.What currently stinks though is if the connection is dead and the next
command I run is a \i, psql just dies instead of re-connecting. It'd be
nice if before reading the script it checked connection status and
attempted a reconnect.At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.+1, I don't think it needs to be the default.
So if we go in this direction, should the option be specified from command
line or available via psqlrc (or both?) I think both make sense.
What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect in non-interactive
mode? I have no use case for that, but it might be different for others.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on / off /
interactive (the last one being the default).
In any case it would make sense to rectify the difference in current
behavior when the failing command is \i somefile.sql. It would be
appropriate to stop parsing the file and reset the connection.
Other thoughts?
--
Alex
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:
On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.I use it all the time for application development; my rebuild script will
forcibly kick everyone out to re-create the database. I put that in because
I invariably end up with a random psql sitting somewhere that I don't want
to track down.What currently stinks though is if the connection is dead and the next
command I run is a \i, psql just dies instead of re-connecting. It'd be nice
if before reading the script it checked connection status and attempted a
reconnect.At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.+1, I don't think it needs to be the default.
So if we go in this direction, should the option be specified from command
line or available via psqlrc (or both?) I think both make sense.What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect in non-interactive
mode? I have no use case for that, but it might be different for others.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on / off /
interactive (the last one being the default).
I think it should just be another psql special variable, like
AUTOCOMMIT or VERBOSITY. If the user wants to set it on the command
line, they can just use -v. We don't need a separate, dedicated
option for this, I think.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2016-11-22 3:46 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
wrote:
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.I use it all the time for application development; my rebuild script
will
forcibly kick everyone out to re-create the database. I put that in
because
I invariably end up with a random psql sitting somewhere that I don't
want
to track down.
What currently stinks though is if the connection is dead and the next
command I run is a \i, psql just dies instead of re-connecting. It'd benice
if before reading the script it checked connection status and attempted
a
reconnect.
At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.+1, I don't think it needs to be the default.
So if we go in this direction, should the option be specified from
command
line or available via psqlrc (or both?) I think both make sense.
What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect in non-interactive
mode? I have no use case for that, but it might be different for others.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on / off /
interactive (the last one being the default).I think it should just be another psql special variable, like
AUTOCOMMIT or VERBOSITY. If the user wants to set it on the command
line, they can just use -v. We don't need a separate, dedicated
option for this, I think.
In this case depends on a default. For almost all scripts the sensible
value is "without reconnect". It be unfriendly to use this setting via -v
variable.
Regards
Pavel
Show quoted text
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Nov 22, 2016 at 5:28 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:
2016-11-22 3:46 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
wrote:
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.I use it all the time for application development; my rebuild script
will
forcibly kick everyone out to re-create the database. I put that in
because
I invariably end up with a random psql sitting somewhere that I don't
want
to track down.
What currently stinks though is if the connection is dead and the next
command I run is a \i, psql just dies instead of re-connecting. It'dbe nice
if before reading the script it checked connection status and
attempted a
reconnect.
At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.+1, I don't think it needs to be the default.
So if we go in this direction, should the option be specified from
command
line or available via psqlrc (or both?) I think both make sense.
What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect in non-interactive
mode? I have no use case for that, but it might be different forothers.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on / off /
interactive (the last one being the default).I think it should just be another psql special variable, like
AUTOCOMMIT or VERBOSITY. If the user wants to set it on the command
line, they can just use -v. We don't need a separate, dedicated
option for this, I think.
That makes sense to me.
In this case depends on a default. For almost all scripts the sensible
value is "without reconnect". It be unfriendly to use this setting via -v
variable.
Well, if you're running a script it should not be affected as long as
default value for this new variable is "interactive" or "off" (and you
didn't override it in psqlrc). If you really want to get a "reconnect even
from the script" type of behavior, then you'll have to use -v or set the
variable from inside the script itself to "on".
--
Alex
2016-11-22 13:02 GMT+01:00 Oleksandr Shulgin <oleksandr.shulgin@zalando.de>:
On Tue, Nov 22, 2016 at 5:28 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:2016-11-22 3:46 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
wrote:
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.I use it all the time for application development; my rebuild script
will
forcibly kick everyone out to re-create the database. I put that in
because
I invariably end up with a random psql sitting somewhere that I don't
want
to track down.
What currently stinks though is if the connection is dead and the next
command I run is a \i, psql just dies instead of re-connecting. It'dbe nice
if before reading the script it checked connection status and
attempted a
reconnect.
At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.+1, I don't think it needs to be the default.
So if we go in this direction, should the option be specified from
command
line or available via psqlrc (or both?) I think both make sense.
What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect innon-interactive
mode? I have no use case for that, but it might be different for
others.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on / off/
interactive (the last one being the default).
I think it should just be another psql special variable, like
AUTOCOMMIT or VERBOSITY. If the user wants to set it on the command
line, they can just use -v. We don't need a separate, dedicated
option for this, I think.That makes sense to me.
In this case depends on a default. For almost all scripts the sensible
value is "without reconnect". It be unfriendly to use this setting via -v
variable.Well, if you're running a script it should not be affected as long as
default value for this new variable is "interactive" or "off" (and you
didn't override it in psqlrc). If you really want to get a "reconnect even
from the script" type of behavior, then you'll have to use -v or set the
variable from inside the script itself to "on".
ok
Pavel
Show quoted text
--
Alex
On Tue, Nov 22, 2016 at 11:06 PM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:
2016-11-22 13:02 GMT+01:00 Oleksandr Shulgin <oleksandr.shulgin@zalando.de
:
On Tue, Nov 22, 2016 at 5:28 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:2016-11-22 3:46 GMT+01:00 Robert Haas <robertmhaas@gmail.com>:
On Mon, Nov 21, 2016 at 4:55 AM, Oleksandr Shulgin
<oleksandr.shulgin@zalando.de> wrote:On Tue, Nov 15, 2016 at 4:10 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
wrote:
On 11/14/16 5:41 AM, Oleksandr Shulgin wrote:
Automatic connection reset is a nice feature for server development,
IMO. Is it really useful for anything else is a good question.I use it all the time for application development; my rebuild script
will
forcibly kick everyone out to re-create the database. I put that in
because
I invariably end up with a random psql sitting somewhere that I
don't want
to track down.
What currently stinks though is if the connection is dead and the
next
command I run is a \i, psql just dies instead of re-connecting. It'd
be nice
if before reading the script it checked connection status and
attempted a
reconnect.
At least an option to control that behavior seems like a good idea,
maybe even set it to 'no reconnect' by default, so that people who
really use it can make conscious choice about enabling it in their
.psqlrc or elsewhere.+1, I don't think it needs to be the default.
So if we go in this direction, should the option be specified from
command
line or available via psqlrc (or both?) I think both make sense.
What should be the option and control variable names? Something like:
--reconnect and RECONNECT? Should we allow reconnect innon-interactive
mode? I have no use case for that, but it might be different for
others.
If non-interactive is not supported then it could be a simple boolean
variable, otherwise we might want something like a tri-state: on /off /
interactive (the last one being the default).
I think it should just be another psql special variable, like
AUTOCOMMIT or VERBOSITY. If the user wants to set it on the command
line, they can just use -v. We don't need a separate, dedicated
option for this, I think.That makes sense to me.
In this case depends on a default. For almost all scripts the sensible
value is "without reconnect". It be unfriendly to use this setting via -v
variable.Well, if you're running a script it should not be affected as long as
default value for this new variable is "interactive" or "off" (and you
didn't override it in psqlrc). If you really want to get a "reconnect even
from the script" type of behavior, then you'll have to use -v or set the
variable from inside the script itself to "on".ok
Closed in 2016-11 commitfest with "returned with feedback" status.
Please feel free to update the status once you submit the updated patch.
Regards,
Hari Babu
Fujitsu Australia