Concurrent psql patch

On May 11, 2007, at 10:55 AM, Gregory Stark wrote:

Also, if anyone has any better ideas for names than \cswitch and
\cnowait
now's the time. I had intended them only as placeholders because I
couldn't
think of anything better but it doesn't sound like anyone else has
any better
ideas either. If not then we're going to be stuck with them. More
or less,
it's explicitly described as an "experimental" feature in the docs
so I
suppose we could always change them later.

I don't see how we could make the names shorter without moving away
from a backslash command (which I'm guessing would be painful).

Assuming we're stuck with a backslash command \cs[witch] and \cn
[owait] seem to be about as good as we could get.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"Jim Nasby" <decibel@decibel.org> writes:

I don't see how we could make the names shorter without moving away from a
backslash command (which I'm guessing would be painful).

Assuming we're stuck with a backslash command \cs[witch] and \cn
[owait] seem to be about as good as we could get.

I don't have \cs or \cn set up as abbreviations.

I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. I'm
not sure if going for cryptic short commands is better or worse here.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:

"Jim Nasby" <decibel@decibel.org> writes:

I don't see how we could make the names shorter without moving
away from a backslash command (which I'm guessing would be
painful).

Assuming we're stuck with a backslash command \cs[witch] and \cn
[owait] seem to be about as good as we could get.

I don't have \cs or \cn set up as abbreviations.

I was originally thinking \c1, \c2, ... for \cswitch and \c& for
\cnowait. I'm not sure if going for cryptic short commands is better
or worse here.

+1 for \c1, \c2, etc.

What's the reasoning behind \c&? Does it "send things into the
background" the way & does in the shell?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate

"David Fetter" <david@fetter.org> writes:

I was originally thinking \c1, \c2, ... for \cswitch and \c& for
\cnowait. I'm not sure if going for cryptic short commands is better
or worse here.

+1 for \c1, \c2, etc.

What's the reasoning behind \c&? Does it "send things into the
background" the way & does in the shell?

Sort of. It sends the *subsequent* command to the background... And unlike the
shell you can't usefully do anything more in the current session while the
command is in the background, you have to manually switch sessions before
issuing subsequent commands.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:

"Jim Nasby" <decibel@decibel.org> writes:

I don't see how we could make the names shorter without moving away from a
backslash command (which I'm guessing would be painful).

Assuming we're stuck with a backslash command \cs[witch] and \cn
[owait] seem to be about as good as we could get.

I don't have \cs or \cn set up as abbreviations.

I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. I'm
not sure if going for cryptic short commands is better or worse here.

Would \c# limit us to 9 concurrent connections? Might want

\cs[witch] [session]

which would switch to the specified session. If none specified, it would
switch back to whatever session was previously active.

\c& sounds fine (as do \c1...\c9). \g& would probably be helpful as well
(send query buffer to server in nowait mode).
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"Jim C. Nasby" <decibel@decibel.org> writes:

On Sun, May 13, 2007 at 02:39:45PM +0100, Gregory Stark wrote:

I was originally thinking \c1, \c2, ... for \cswitch and \c& for \cnowait. I'm
not sure if going for cryptic short commands is better or worse here.

\c& sounds fine (as do \c1...\c9). \g& would probably be helpful as well
(send query buffer to server in nowait mode).

Er, I just realized I typed the wrong thing there. It can't be \c& since I do
assign a meaning to that "make a new connection to the same place as this
one".

I meant \&

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:

"David Fetter" <david@fetter.org> writes:

What's the reasoning behind \c&? Does it "send things into the
background" the way & does in the shell?

Sort of. It sends the *subsequent* command to the background...

That sounds just bizarre. Existing backslash commands that do something
to a SQL command are typed *after* the command they affect (\g for
instance). I don't think you should randomly change that.

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Gregory Stark <stark@enterprisedb.com> writes:

"David Fetter" <david@fetter.org> writes:

What's the reasoning behind \c&? Does it "send things into the
background" the way & does in the shell?

Sort of. It sends the *subsequent* command to the background...

That sounds just bizarre. Existing backslash commands that do something
to a SQL command are typed *after* the command they affect (\g for
instance). I don't think you should randomly change that.

So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with just
declaring that asynchronous commands must be issued using \g& rather than use
the semicolon to fire them off.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:

So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with just
declaring that asynchronous commands must be issued using \g& rather than use
the semicolon to fire them off.

It makes sense to me... but what is the state of the session afterward?
Should this be combined with switching to another connection?

regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Gregory Stark <stark@enterprisedb.com> writes:

So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with just
declaring that asynchronous commands must be issued using \g& rather than use
the semicolon to fire them off.

It makes sense to me... but what is the state of the session afterward?
Should this be combined with switching to another connection?

It's an interesting idea since you'll inevitably have to switch connections.
If you issue a second query it'll forces the session to wait for the results.
(It doesn't seem like there's any point in keeping a queue of pending queries
per session.)

However we do still need a command to switch back anyways so there doesn't
seem to be any advantage in combining the two.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

"Jim C. Nasby" <decibel@decibel.org> writes:

Would \c# limit us to 9 concurrent connections? Might want

\cs[witch] [session]

Hm, we kind of have a choice with \c#. Either we treat it as part of the
command in which case the way to connect to an integer-named database is to
include a space. We could even have it magically connect to a database if the
connection isn't already active.

But these kinds of inconsistent behaviours can be traps for users. It means
"\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
do the same thing. And it means "\c1" might connect to a database named "1"
today but switch sessions tomorrow.

Or we treat it as the first argument in which case even "\c 9" switches to
session 9. I would prefer to do that but I fear there may be people with
databases named "9".

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:

But these kinds of inconsistent behaviours can be traps for users. It means
"\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
do the same thing. And it means "\c1" might connect to a database named "1"
today but switch sessions tomorrow.

The real problem here is trying to overload an existing command name
with too many different meanings. You need to pick some other name
besides \c.

If you were willing to think of it as "switch session" instead of "connect",
then \S is available ...

regards, tom lane

On Mon, May 14, 2007 at 12:51:39PM +0100, Gregory Stark wrote:

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

Gregory Stark <stark@enterprisedb.com> writes:

So would you prefer \g& as Jim Nasby suggested? I hadn't even considered that
previously since I'm not accustomed to using \g but it does seem kind of
pretty. I normally use ; but I suppose there's nothing wrong with just
declaring that asynchronous commands must be issued using \g& rather than use
the semicolon to fire them off.

It makes sense to me... but what is the state of the session afterward?
Should this be combined with switching to another connection?

It's an interesting idea since you'll inevitably have to switch connections.
If you issue a second query it'll forces the session to wait for the results.
(It doesn't seem like there's any point in keeping a queue of pending queries
per session.)

However we do still need a command to switch back anyways so there doesn't
seem to be any advantage in combining the two.

I'd thought about this, and the question I came up with was: what
connection should we switch to? First thought was to switch back to
whatever connection we'd been using before this one, but then you'd
quickly have 2 connections tied up... then what?

If someone could come up with a logical session to connect to
automatically that'd be great. In the meantime, what about allowing \g&
accept a connection number to switch to?

Also, I'd really love it if we could also do ';&'... I didn't mention it
before because I'm assuming it's essentially not possible, but I'd like
to be wrong...
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:

Gregory Stark <stark@enterprisedb.com> writes:

But these kinds of inconsistent behaviours can be traps for users. It means
"\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
do the same thing. And it means "\c1" might connect to a database named "1"
today but switch sessions tomorrow.

The real problem here is trying to overload an existing command name
with too many different meanings. You need to pick some other name
besides \c.

If you were willing to think of it as "switch session" instead of "connect",
then \S is available ...

Since this command will be getting used very frequently by anyone using
concurrent connections interactively, it'd be nice if it was lower-case.
It looks like that limits us to j, k, m, n, v, and y. In unix this idea
is about jobs, what about using \j?
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

"Jim C. Nasby" <decibel@decibel.org> writes:

Since this command will be getting used very frequently by anyone using
concurrent connections interactively, it'd be nice if it was lower-case.
It looks like that limits us to j, k, m, n, v, and y. In unix this idea
is about jobs, what about using \j?

Well currently it's not really terribly interesting to use interactively since
you could always just start a second shell and run a second instance of psql.
I really only have regression tests in mind for it. That's why I don't find it
a problem at all to only extend \g and not semicolon handling.

That said, I think a next step for this for interactive use would be to handle
C-z to "background" the currently running query. So perhaps it does make sense
to keep use cases like that when deciding on command names now.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

On Mon, May 14, 2007 at 06:26:42PM +0100, Gregory Stark wrote:

"Jim C. Nasby" <decibel@decibel.org> writes:

Since this command will be getting used very frequently by anyone using
concurrent connections interactively, it'd be nice if it was lower-case.
It looks like that limits us to j, k, m, n, v, and y. In unix this idea
is about jobs, what about using \j?

Well currently it's not really terribly interesting to use interactively since
you could always just start a second shell and run a second instance of psql.
I really only have regression tests in mind for it. That's why I don't find it
a problem at all to only extend \g and not semicolon handling.

That said, I think a next step for this for interactive use would be to handle
C-z to "background" the currently running query. So perhaps it does make sense
to keep use cases like that when deciding on command names now.

Yeah, I think having the ability to open up another connection within
psql will turn out to be very useful from an interactive standpoint; \c&
(or whatever command we use to duplicate the current connection) is
going to be a lot easier to enter than actually starting up a new psql
in many production environments.
--
Jim Nasby decibel@decibel.org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

On Mon, May 14, 2007 at 11:55:07AM -0500, Jim C. Nasby wrote:

On Mon, May 14, 2007 at 11:03:52AM -0400, Tom Lane wrote:

Gregory Stark <stark@enterprisedb.com> writes:

But these kinds of inconsistent behaviours can be traps for users. It means
"\c1" and "\c 1" do different things even though "\cpostgres" and \c postgres"
do the same thing. And it means "\c1" might connect to a database named "1"
today but switch sessions tomorrow.

The real problem here is trying to overload an existing command name
with too many different meanings. You need to pick some other name
besides \c.

If you were willing to think of it as "switch session" instead of "connect",
then \S is available ...

Since this command will be getting used very frequently by anyone using
concurrent connections interactively, it'd be nice if it was lower-case.
It looks like that limits us to j, k, m, n, v, and y. In unix this idea
is about jobs, what about using \j?

I suppose there is some reason the bash/csh job control characters:

%-
%+
%1

won't work?

-dg

--
David Gould daveg@sonic.net
If simplicity worked, the world would be overrun with insects.

So based on the feedback and suggestions here this is the interface I suggest:

\connect& - to open a new connection keeping the existing one
\g& - to submit a command asynchronously (like & in the shell)
\S [Sess#] - to _S_witch to a different _S_ession
- if no connection # specified list available _S_essions
\D - _D_isconnect from current session (like ^D in the shell)

This leaves no way to submit an asynchronous command without using \g but I'm
really not too concerned with that. I don't want to start messing with psql's
semicolon parsing behaviour and I'm mainly only concerned with this for
regression tests.

Another thought I had for the future is a \C command to simulate C-c and send
a query cancel. That would let us have regression tests that query
cancellation worked. The tests would presumably have to be written using
pg_sleep() to ensure they ran for long enough but even then there would be no
way to control exactly when the interrupt arrived.

Attached is an updated patch.

I also found and fixed some missing ResetCancelConn()s. I think I got them all
and the behaviour seems correct in practice when cancelling various
combinations of synchronous queries, asynchronous queries, and backslash
commands. The one thing I wonder about is that I'm a bit concerned I may have
introduced an assumption about how many resultsets arrive from a single query.

I'll be offline for a few days but I'll be back Monday.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Gregory Stark wrote:

So based on the feedback and suggestions here this is the interface I suggest:

\connect& - to open a new connection keeping the existing one
\g& - to submit a command asynchronously (like & in the shell)
\S [Sess#] - to _S_witch to a different _S_ession
- if no connection # specified list available _S_essions
\D - _D_isconnect from current session (like ^D in the shell)

This leaves no way to submit an asynchronous command without using \g but I'm
really not too concerned with that. I don't want to start messing with psql's
semicolon parsing behaviour and I'm mainly only concerned with this for
regression tests.

Another thought I had for the future is a \C command to simulate C-c and send
a query cancel. That would let us have regression tests that query
cancellation worked. The tests would presumably have to be written using
pg_sleep() to ensure they ran for long enough but even then there would be no
way to control exactly when the interrupt arrived.

Attached is an updated patch.

I also found and fixed some missing ResetCancelConn()s. I think I got them all
and the behaviour seems correct in practice when cancelling various
combinations of synchronous queries, asynchronous queries, and backslash
commands. The one thing I wonder about is that I'm a bit concerned I may have
introduced an assumption about how many resultsets arrive from a single query.

I'll be offline for a few days but I'll be back Monday.

[ Attachment, skipping... ]

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +