Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxYvS-0003yL-BH for pgadmin-hackers@arkaria.postgresql.org; Fri, 21 Oct 2016 12:27:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bxYvR-0006gI-Tv for pgadmin-hackers@arkaria.postgresql.org; Fri, 21 Oct 2016 12:27:53 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bxYvP-0006cQ-Vp for pgadmin-hackers@postgresql.org; Fri, 21 Oct 2016 12:27:52 +0000 Received: from mail-qk0-x229.google.com ([2607:f8b0:400d:c09::229]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bxYvN-00068s-1q for pgadmin-hackers@postgresql.org; Fri, 21 Oct 2016 12:27:50 +0000 Received: by mail-qk0-x229.google.com with SMTP id z190so148936484qkc.2 for ; Fri, 21 Oct 2016 05:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PLDtlTmMOAJWhb01mYOAmxXrwwSgFEgu/a0sVZN0CTw=; b=j7WZMBvVOByoqKu0gjvQmXGkGKXwJV8nXN9vD+laI11DqNF6jE74qPtxNSBsJI6H9c w2R0yC0ZQRuKuTsXrzLPliHmpcZmpgKiFgVuFvPCtGcgMWf2aWG9eMDjBHo3SY8oJ1x0 Gd3k8QV7v3Vfh2KhTYHY479olKshc3SLQY5W8CyjKXZWpUjKPsdmX15ARODPsZUhfcbJ mhLplunmsnHJHtxu5J63HqPUPFyfnXonPWWgf1IyBNEoGeyNGWXqX2P06jHBWREd+MF4 va58pYnD9Wtr5jkRRYNN7pzd1KE4zk6cabsNvNYh8bGcexzNyIKHE5LWWDW00HilQilM 1T9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PLDtlTmMOAJWhb01mYOAmxXrwwSgFEgu/a0sVZN0CTw=; b=CN7H2A19kFf/3L6ede9xdd+gG/LSnmxa8lkzS92A7LTBoVyVxZPRV69FNY1bLTrk7e UuuFUN+bz9bj7S9r0a3tIMlFJv7t5zYm3D5Ns0s/vv5uOo9361HMciigTMJNhQpOfJi5 lSqpyzI+voQz0YUY7hPrLfA1EXoPcbF3MZQL+f+Whf9wOMVxm2XFrHh1HZsgqZdWN9NB 99FXPPKqtGeY3LPU7yAw7fDyV3IVcF9LpQpMwFYxEnjGC9miRoakqTVT537IWGJs6Q3T oJYhDbu2WBdpN3X3Om4wbu436304i4sTykVd1YLe2t6opMbZyS3YBw/UyWKzGo7EIuA6 m6yg== X-Gm-Message-State: ABUngvdhCY7OzMcJxBLHgblRWQhKxktie7gzoVALEuQEgRAsd2Jy7fbDulGkfowpT7o5rLDOBtRt2m/PJrSKp6ki X-Received: by 10.194.115.38 with SMTP id jl6mr575126wjb.52.1477052868145; Fri, 21 Oct 2016 05:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.227 with HTTP; Fri, 21 Oct 2016 05:27:47 -0700 (PDT) In-Reply-To: References: From: Neel Patel Date: Fri, 21 Oct 2016 17:57:47 +0530 Message-ID: Subject: Re: PATCH: To fix the issue in Debugger module (pgAdmin4) To: Dave Page Cc: Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary=001a1130d05a854648053f5f2b7f X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a1130d05a854648053f5f2b7f Content-Type: text/plain; charset=UTF-8 Hi, On Fri, Oct 21, 2016 at 5:03 PM, Dave Page wrote: > Hi > > On Fri, Oct 21, 2016 at 12:32 PM, Neel Patel > wrote: > > Hi, > > > > > > On Fri, Oct 21, 2016 at 4:48 PM, Dave Page wrote: > >> > >> Hi > >> > >> There are still issues I'm afraid: > >> > >> - When execution stops, we seem to keep polling for more results > >> indefinitely. > > > > Do you mean after completion of first successful debugging ? > > If yes, we are polling because user can start same function for debugging > > again and we have to listen for the result set for that session. > > Yes (or the second). But shouldn't we stop polling until debugging is > restarted? > I think yes, that can be done. > > >> > >> > >> - When executing for a second time, the messages tab isn't cleared, > >> and new messages don't seem to be appended to it either. I would > >> expect the tab to be cleared. > > > > > > Ok. We will fix this issue. > >> > >> > >> On Thu, Oct 20, 2016 at 9:14 AM, Murtuza Zabuawala > >> wrote: > >> > Hi Dave, > >> > > >> > PFA updated patch for the same. > >> > > >> > Issue: > >> > We were not properly fetching result from server in case of direct > >> > debugging > >> > when we restart debugging of same object. > >> > > >> > Thanks to Neel for helping in this issue. > >> > > >> > Please review. > >> > > >> > -- > >> > Regards, > >> > Murtuza Zabuawala > >> > EnterpriseDB: http://www.enterprisedb.com > >> > The Enterprise PostgreSQL Company > >> > > >> > On Fri, Oct 7, 2016 at 5:32 PM, Dave Page wrote: > >> >> > >> >> On Fri, Oct 7, 2016 at 12:53 PM, Dave Page > wrote: > >> >> > On Fri, Oct 7, 2016 at 12:42 PM, Murtuza Zabuawala > >> >> > wrote: > >> >> >> Hi Dave, > >> >> >> > >> >> >> I faced the same issue when I initially tried that, but then as > per > >> >> >> Neel > >> >> >> suggestion I changed SELECT pg_sleep() to PERFORM pg_sleep() in > >> >> >> function. > >> >> >> You will face the same in pgAdmin3 if you use select pg_sleep() in > >> >> >> your > >> >> >> function the debug call never returns from DB server. > >> >> > > >> >> > In which case, doesn't that imply the debugger is missing critical > >> >> > debug info? If I run the query in the query tool, I get: > >> >> > > >> >> > ==== > >> >> > INFO: EMPNO ENAME > >> >> > INFO: ----- ------- > >> >> > ERROR: query has no destination for result data > >> >> > HINT: If you want to discard the results of a SELECT, use PERFORM > >> >> > instead. > >> >> > CONTEXT: PL/pgSQL function list_emp() line 11 at SQL statement > >> >> > > >> >> > > >> >> > Query returned successfully in 2 secs. > >> >> > ==== > >> >> > > >> >> > It seems to me that the debugger should be able to give the same > >> >> > error. > >> >> > > >> >> > Regardless of that, I'll test with PERFORM. > >> >> > >> >> Which I just did - and whilst it seemed to be fine when stepping > >> >> through, after a few iterations I hit the continue button, at which > >> >> point it froze again on "PERFORM pg_sleep(2)", didn't print any more > >> >> of the 14 names in the emp table, and didn't return :-( > >> >> > >> >> -- > >> >> Dave Page > >> >> Blog: http://pgsnake.blogspot.com > >> >> Twitter: @pgsnake > >> >> > >> >> EnterpriseDB UK: http://www.enterprisedb.com > >> >> The Enterprise PostgreSQL Company > >> > > >> > > >> > >> > >> > >> -- > >> Dave Page > >> Blog: http://pgsnake.blogspot.com > >> Twitter: @pgsnake > >> > >> EnterpriseDB UK: http://www.enterprisedb.com > >> The Enterprise PostgreSQL Company > >> > >> > >> -- > >> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) > >> To make changes to your subscription: > >> http://www.postgresql.org/mailpref/pgadmin-hackers > > > > > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --001a1130d05a854648053f5f2b7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


On Fri, Oct 21, 2016 at 5:03 PM, Dave Page <dpage@pgadmi= n.org> wrote:
Hi

On Fri, Oct 21, 2016 at 12:32 PM, Neel Patel
<neel.patel@enterprisedb.= com> wrote:
> Hi,
>
>
> On Fri, Oct 21, 2016 at 4:48 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> There are still issues I'm afraid:
>>
>> - When execution stops, we seem to keep polling for more results >> indefinitely.
>
> Do you mean after completion of first successful debugging ?
> If yes, we are polling because user can start same function for debugg= ing
> again and we have to listen for the result set for that session.

Yes (or the second). But shouldn't we stop polling until debuggi= ng is restarted?
=C2=A0
I think yes, that ca= n be done.

>>
>>
>> - When executing for a second time, the messages tab isn't cle= ared,
>> and new messages don't seem to be appended to it either. I wou= ld
>> expect the tab to be cleared.
>
>
> Ok. We will fix this issue.
>>
>>
>> On Thu, Oct 20, 2016 at 9:14 AM, Murtuza Zabuawala
>> <murtuza.= zabuawala@enterprisedb.com> wrote:
>> > Hi Dave,
>> >
>> > PFA updated patch for the same.
>> >
>> > Issue:
>> > We were not properly fetching result from server in case of d= irect
>> > debugging
>> > when we restart debugging of same object.
>> >
>> > Thanks to Neel for helping in this issue.
>> >
>> > Please review.
>> >
>> > --
>> > Regards,
>> > Murtuza Zabuawala
>> > EnterpriseDB: http://www.enterprisedb.com
>> > The Enterprise PostgreSQL Company
>> >
>> > On Fri, Oct 7, 2016 at 5:32 PM, Dave Page <dpage@pgadmin.org> wrote:
>> >>
>> >> On Fri, Oct 7, 2016 at 12:53 PM, Dave Page <dpage@pgadmin.org> wrote:
>> >> > On Fri, Oct 7, 2016 at 12:42 PM, Murtuza Zabuawala >> >> > <murtuza.zabuawala@enterprisedb.com> wrote:
>> >> >> Hi Dave,
>> >> >>
>> >> >> I faced the same issue when I initially tried th= at, but then as per
>> >> >> Neel
>> >> >> suggestion I changed SELECT pg_sleep() to PERFOR= M pg_sleep() in
>> >> >> function.
>> >> >> You will face the same in pgAdmin3 if you use se= lect pg_sleep() in
>> >> >> your
>> >> >> function the debug call never returns from DB se= rver.
>> >> >
>> >> > In which case, doesn't that imply the debugger i= s missing critical
>> >> > debug info? If I run the query in the query tool, I = get:
>> >> >
>> >> > =3D=3D=3D=3D
>> >> > INFO:=C2=A0 EMPNO=C2=A0 =C2=A0 ENAME
>> >> > INFO:=C2=A0 -----=C2=A0 =C2=A0 -------
>> >> > ERROR:=C2=A0 query has no destination for result dat= a
>> >> > HINT:=C2=A0 If you want to discard the results of a = SELECT, use PERFORM
>> >> > instead.
>> >> > CONTEXT:=C2=A0 PL/pgSQL function list_emp() line 11 = at SQL statement
>> >> >
>> >> >
>> >> > Query returned successfully in 2 secs.
>> >> > =3D=3D=3D=3D
>> >> >
>> >> > It seems to me that the debugger should be able to g= ive the same
>> >> > error.
>> >> >
>> >> > Regardless of that, I'll test with PERFORM.
>> >>
>> >> Which I just did - and whilst it seemed to be fine when s= tepping
>> >> through, after a few iterations I hit the continue button= , at which
>> >> point it froze again on "PERFORM pg_sleep(2)", = didn't print any more
>> >> of the 14 names in the emp table, and didn't return := -(
>> >>
>> >> --
>> >> Dave Page
>> >> Blog: http://pgsnake.blogspot.com
>> >> Twitter: @pgsnake
>> >>
>> >> EnterpriseDB UK: http://www.enterprisedb.com
>> >> The Enterprise PostgreSQL Company
>> >
>> >
>>
>>
>>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> --
>> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/p= gadmin-hackers
>
>



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--001a1130d05a854648053f5f2b7f--