Re: PATCH: To fix the issue in Debugger module (pgAdmin4)

Thanks - committed with minor changes to hide the busy cursor when
execution completes and to fix some comments.

On Fri, Nov 11, 2016 at 12:02 PM, Murtuza Zabuawala
<murtuza(dot)zabuawala(at)enterprisedb(dot)com> wrote:
> Hi Dave,
>
> PFA updated patch, Both of the issues pointed by you in last email are
> addressed in this patch.
> Please review.
>
> RM#1227
>
>
> --
> Regards,
> Murtuza Zabuawala
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
> On Fri, Oct 21, 2016 at 5:57 PM, Neel Patel <neel(dot)patel(at)enterprisedb(dot)com>
> wrote:
>>
>> Hi,
>>
>>
>> On Fri, Oct 21, 2016 at 5:03 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>> Hi
>>>
>>> On Fri, Oct 21, 2016 at 12:32 PM, Neel Patel
>>> <neel(dot)patel(at)enterprisedb(dot)com> wrote:
>>> > Hi,
>>> >
>>> >
>>> > On Fri, Oct 21, 2016 at 4:48 PM, Dave Page <dpage(at)pgadmin(dot)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
>>> > 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?
>>
>>
>
> Fixed
>>
>> 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.
>>> >
>
> Fixed
>>>
>>> >
>>> > Ok. We will fix this issue.
>>> >>
>>> >>
>>> >> On Thu, Oct 20, 2016 at 9:14 AM, Murtuza Zabuawala
>>> >> <murtuza(dot)zabuawala(at)enterprisedb(dot)com> 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 <dpage(at)pgadmin(dot)org> wrote:
>>> >> >>
>>> >> >> On Fri, Oct 7, 2016 at 12:53 PM, Dave Page <dpage(at)pgadmin(dot)org>
>>> >> >> wrote:
>>> >> >> > On Fri, Oct 7, 2016 at 12:42 PM, Murtuza Zabuawala
>>> >> >> > <murtuza(dot)zabuawala(at)enterprisedb(dot)com> 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(at)postgresql(dot)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
>>
>>
>

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

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