From: | Murtuza Zabuawala <murtuza(dot)zabuawala(at)enterprisedb(dot)com> |
---|---|
To: | Neel Patel <neel(dot)patel(at)enterprisedb(dot)com> |
Cc: | Dave Page <dpage(at)pgadmin(dot)org>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH: To fix the issue in Debugger module (pgAdmin4) |
Date: | 2016-11-11 12:02:19 |
Message-ID: | CAKKotZR1fL-ykdL0o9FuVVKe_YAwESbvVBpZKYZMAxukp50z3w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
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
>>
>
>
Attachment | Content-Type | Size |
---|---|---|
RM_1227_v8.patch | application/octet-stream | 17.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2016-11-11 12:40:34 | Re: QtWebEngine issue |
Previous Message | Dave Page | 2016-11-11 10:55:34 | pgAdmin 4 commit: Fix a fairly improtant typo! |