Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxY43-0007wT-3N for pgadmin-hackers@arkaria.postgresql.org; Fri, 21 Oct 2016 11:32:43 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bxY42-000673-Kj for pgadmin-hackers@arkaria.postgresql.org; Fri, 21 Oct 2016 11:32:42 +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 1bxY41-00066x-TK for pgadmin-hackers@postgresql.org; Fri, 21 Oct 2016 11:32:42 +0000 Received: from mail-qk0-x22a.google.com ([2607:f8b0:400d:c09::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bxY3z-00058X-2H for pgadmin-hackers@postgresql.org; Fri, 21 Oct 2016 11:32:40 +0000 Received: by mail-qk0-x22a.google.com with SMTP id n189so146546407qke.0 for ; Fri, 21 Oct 2016 04:32:38 -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=gu7hZc301EZLNTEBLYCxyrRsKe+m99Uvp6FQ5Fvl7No=; b=1AkFwMna/KASUfuNeaSzl0hhdZ/PEW/94ehSJk1T/ga34hlW3RoY1mFfvBHzj5bepU 2hObMXjx5yijDLn71FiprukCX46uNiIzj8K790I3sbZkYzA/4AIIdCJs3nmmtdIcOyrp 94d2qpTHlLxZ45Y/0vX5Xrsj+MrbOcy60pELfyoiT8+XKu25qvTKkOPTT6sBG9PAZVvE cgsfujv/tu126Oop1dpyAVNmwd2RNbM17T9dQOvZDt4tQv9qgoZpVdKLWjMLSk6Mbt/a WGX0g8TU7dJaMnphnz4kvUvQ/N2eevig7s5KoqTim1fwBZenxDB7h6rI6+7Mx8+fbOAg vI1Q== 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=gu7hZc301EZLNTEBLYCxyrRsKe+m99Uvp6FQ5Fvl7No=; b=V3zIL6MRd4mxVvpo70tTL/ZnhdRH5Enu3W4BpFNJV4tEECZFcDTcWqjYn0OC3gyZA+ QrsqImJhyn3bhWq68m72n8k35jftA0+ZQ+x2qeAvO5R6WKChbgY1Svyyq2iHHVHmoceE nhZ9ZLIOwoNlOBgX3Mrvlv+goxHw0prBtOo6+5HzZpTeTjgGYhGSIw19HRw2hYqAWfEI iIqooh7BcmTenU1w+Kc4vJ4ZLbUspkbTXN4VR77e/e2O/CcRVV33XDBAs8T/ZlqSo9a0 CHW26k3RvxwVKiD1egjrFY7NYaq7ah0hhVMbQFkkqO49+0F/gNspiXOrTYsdaxRrvB5v fyeA== X-Gm-Message-State: ABUngve3w0m4DoDAEerKi3WBv4ah2h6LEdZsIVFHQghlH8XeetlHIgxuPBHsp7FevT6/5so0170ahA4o1/5NYqs7 X-Received: by 10.194.115.38 with SMTP id jl6mr378892wjb.52.1477049558134; Fri, 21 Oct 2016 04:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.227 with HTTP; Fri, 21 Oct 2016 04:32:37 -0700 (PDT) In-Reply-To: References: From: Neel Patel Date: Fri, 21 Oct 2016 17:02:37 +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=001a1130d05a3a88d2053f5e66b0 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 --001a1130d05a3a88d2053f5e66b0 Content-Type: text/plain; charset=UTF-8 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. > > - 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 > --001a1130d05a3a88d2053f5e66b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


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

There are still issues I'm afraid:

- When execution stops, we seem to keep polling for more results indefinite= ly.
Do you mean after completion of first successful d= ebugging ?=C2=A0
If yes, we are polling because user can start sa= me function for debugging again and we have to listen for the result set fo= r that session.

- 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.
=C2=A0
Ok. We = will fix this issue.=C2=A0

On Thu, Oct 20, 2016 at 9:14 AM, Murtuza Zabuawala
<murtuza.zabuawala@enterprisedb.com> wrot= e:
> Hi Dave,
>
> PFA updated patch for the same.
>
> Issue:
> We were not properly fetching result from server in case of direct deb= ugging
> 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
>> > <mur= tuza.zabuawala@enterprisedb.com> wrote:
>> >> Hi Dave,
>> >>
>> >> I faced the same issue when I initially tried that, but t= hen as per
>> >> Neel
>> >> suggestion I changed SELECT pg_sleep() to PERFORM pg_slee= p() in
>> >> function.
>> >> You will face the same in pgAdmin3 if you use select pg_s= leep() 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:
>> >
>> > =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 data
>> > HINT:=C2=A0 If you want to discard the results of a SELECT, u= se PERFORM
>> > instead.
>> > CONTEXT:=C2=A0 PL/pgSQL function list_emp() line 11 at SQL st= atement
>> >
>> >
>> > Query returned successfully in 2 secs.
>> > =3D=3D=3D=3D
>> >
>> > It seems to me that the debugger should be able to give the s= ame 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 whic= h
>> 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-ha= ckers

--001a1130d05a3a88d2053f5e66b0--