Thread: \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
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;
/* 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
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
On Thu, May 2, 2013 at 10:01:28AM -0400, Tom Lane wrote:> Michael Paquier <michael.paquier@gmail.com> writes:> > Hiall,> > When testing \watch, I noticed that process waits indefinitely when> > executing it with a DDL or a DML.> > Forexample:> > 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 ebe0b236909732c75d665c73363bd4ac7a7aa138Author: 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. +
On Thu, May 2, 2013 at 11:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
MichaelMichael Paquier <michael.paquier@gmail.com> writes:It's not "waiting", it's doing the ANALYZE once every ten seconds,
> 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
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
that other commands returning tuples have, giving something like that:
Watch every 2s Fri May 3 10:01:04 2013
$TAG
Regards,
-- 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
On Sun, May 5, 2013 at 5:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
--
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 aDone that way, thanks for the suggestion.
>> 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
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 +0000 > > Add 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
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 +0000 >> >> Add 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
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
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. +