\watch stuck on execution of commands returning no tuples
Hi all,
When testing \watch, I noticed that process waits indefinitely when
executing it with a DDL or a DML.
For example:
postgres=# CREATE TABLE aa (a int);
postgres=# ANALYSE aa \watch 10
-- Process waiting here
By referring at do_watch:command.c, the feature is made such as there is no
error if command returns no tuples:
default:
/* should we fail for non-tuple-result commands? */
break;
The user can interrupt the process if wanted, but shouldn't it make more
sense to return directly an error to the user instead of making the process
wait indefinitely?
Regards,
--
Michael
Michael Paquier <michael.paquier@gmail.com> writes:
Hi all,
When testing \watch, I noticed that process waits indefinitely when
executing it with a DDL or a DML.
For example:
postgres=# CREATE TABLE aa (a int);
postgres=# ANALYSE aa \watch 10
-- Process waiting here
It's not "waiting", it's doing the ANALYZE once every ten seconds,
just like you told it to.
Perhaps it'd be a good idea to emit the command tag on receiving a
non-tuple-bearing result, just to make this more obvious.
regards, tom lane
--
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, May 2, 2013 at 10:01:28AM -0400, Tom Lane wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
Hi all,
When testing \watch, I noticed that process waits indefinitely when
executing it with a DDL or a DML.
For example:
postgres=# CREATE TABLE aa (a int);
--> > > postgres=# ANALYSE aa \watch 10
-------
-- Process waiting here
OK, what other database supports British spelling of commands? Can we
call this a compatibility feature. ;-) The feature has been there
since 2000:
commit ebe0b236909732c75d665c73363bd4ac7a7aa138
Author: Bruce Momjian <bruce@momjian.us>
Date: Wed Nov 8 21:28:06 2000 +0000
Add ANALYSE spelling of ANALYZE for vacuum.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
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, May 2, 2013 at 11:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
Hi all,
When testing \watch, I noticed that process waits indefinitely when
executing it with a DDL or a DML.
For example:
postgres=# CREATE TABLE aa (a int);
postgres=# ANALYSE aa \watch 10
-- Process waiting hereIt's not "waiting", it's doing the ANALYZE once every ten seconds,
just like you told it to.Perhaps it'd be a good idea to emit the command tag on receiving a
non-tuple-bearing result, just to make this more obvious.
Yes, the command tag would be a good idea, combined with the watch time
that other commands returning tuples have, giving something like that:
Watch every 2s Fri May 3 10:01:04 2013
$TAG
Regards,
--
Michael
Michael Paquier <michael.paquier@gmail.com> writes:
On Thu, May 2, 2013 at 11:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Perhaps it'd be a good idea to emit the command tag on receiving a
non-tuple-bearing result, just to make this more obvious.
Yes, the command tag would be a good idea, combined with the watch time
that other commands returning tuples have, giving something like that:
Watch every 2s Fri May 3 10:01:04 2013
$TAG
Done that way, thanks for the suggestion.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, May 5, 2013 at 5:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
On Thu, May 2, 2013 at 11:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Perhaps it'd be a good idea to emit the command tag on receiving a
non-tuple-bearing result, just to make this more obvious.Yes, the command tag would be a good idea, combined with the watch time
that other commands returning tuples have, giving something like that:
Watch every 2s Fri May 3 10:01:04 2013
$TAGDone that way, thanks for the suggestion.
Thanks a lot for the fix.
--
Michael
On Thu, May 2, 2013 at 7:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
OK, what other database supports British spelling of commands? Can we
call this a compatibility feature. ;-) The feature has been there
since 2000:commit ebe0b236909732c75d665c73363bd4ac7a7aa138
Author: Bruce Momjian <bruce@momjian.us>
Date: Wed Nov 8 21:28:06 2000 +0000Add ANALYSE spelling of ANALYZE for vacuum.
Maybe we should also support ANALIZAR, ANALYSER, and 分析する.
(I don't know whether I'm joking, so don't ask.)
--
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
2013/5/8 Robert Haas <robertmhaas@gmail.com>:
On Thu, May 2, 2013 at 7:53 PM, Bruce Momjian <bruce@momjian.us> wrote:
OK, what other database supports British spelling of commands? Can we
call this a compatibility feature. ;-) The feature has been there
since 2000:commit ebe0b236909732c75d665c73363bd4ac7a7aa138
Author: Bruce Momjian <bruce@momjian.us>
Date: Wed Nov 8 21:28:06 2000 +0000Add ANALYSE spelling of ANALYZE for vacuum.
Maybe we should also support ANALIZAR, ANALYSER, and 分析する.
As a British native speaker involved in translating some PostgreSQL-related
Japanese text, all I can say is "yes please". (Although for true Japanese
support, the grammar would have to be pretty much reversed, with the verb
being placed last; and WHERE would come before SELECT, which might
challenge the parser a little).
(I don't know whether I'm joking, so don't ask.)
I think I am joking.
Regards
Ian Barwick
--
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, May 7, 2013 at 2:36 PM, Ian Lawrence Barwick <barwick@gmail.com> wrote:
As a British native speaker involved in translating some PostgreSQL-related
Japanese text, all I can say is "yes please". (Although for true Japanese
support, the grammar would have to be pretty much reversed, with the verb
being placed last; and WHERE would come before SELECT, which might
challenge the parser a little).
I am personally of the opinion that whoever designed SQL was far too
concerned about making it look like English and insufficiently
concerned about making it pleasant to use. Since the target list
comes before the FROM clause, you see (or must write) what you want to
select from which table aliases before defining what those table
aliases mean. Overall, you end up with an organization where you
define the aliases in the middle, and then half the stuff that uses
those definitions is at the beginning (in the target list) while the
other half is at the end (in the WHERE clause). Strange!
But, it's a standard, so, we live with it. And, none of the query
languages I've designed have gained quite as much traction as SQL, so
who am I to complain?
(I don't know whether I'm joking, so don't ask.)
I think I am joking.
Keep me posted as things develop. :-)
--
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
On Tue, May 7, 2013 at 02:47:16PM -0400, Robert Haas wrote:
On Tue, May 7, 2013 at 2:36 PM, Ian Lawrence Barwick <barwick@gmail.com> wrote:
As a British native speaker involved in translating some PostgreSQL-related
Japanese text, all I can say is "yes please". (Although for true Japanese
support, the grammar would have to be pretty much reversed, with the verb
being placed last; and WHERE would come before SELECT, which might
challenge the parser a little).I am personally of the opinion that whoever designed SQL was far too
concerned about making it look like English and insufficiently
concerned about making it pleasant to use. Since the target list
comes before the FROM clause, you see (or must write) what you want to
select from which table aliases before defining what those table
aliases mean. Overall, you end up with an organization where you
define the aliases in the middle, and then half the stuff that uses
those definitions is at the beginning (in the target list) while the
other half is at the end (in the WHERE clause). Strange!But, it's a standard, so, we live with it. And, none of the query
languages I've designed have gained quite as much traction as SQL, so
who am I to complain?
It is confusing to explain to people that in a SELECT, everything from
the FROM clause down is executed in order, then the target list.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers