MIME-Version: 1.0
In-Reply-To: 
 <CACCA4P2BOCiNDisEfTi_aSTSugUFTjZea-YZ-AWZNSBN8Lj63w@mail.gmail.com>
References: 
 <CAKKotZQz6mGEiky_Szo91tzm_RFvwJTYGriTmuxVYrhcWi5nJg@mail.gmail.com>
 <CA+OCxoxkphr1YF6F53j3sTreTMvoBOKqV+wjF6CnxoQ-SA+rzA@mail.gmail.com>
 <CAKKotZRMetEEPzFTuqiw_8Vit2_STHSN22=K+5frJBu7=Jp6PQ@mail.gmail.com>
 <CAKKotZQGdhiFrtNK0xz8OVLKOA2QCk_yfOZDFT+HEMfELzbk4A@mail.gmail.com>
 <CA+OCxoyzS4_cST0qJ7CbmxqOry4wGZCQkoiLpcXgjr2N4snPQw@mail.gmail.com>
 <CAKKotZSjyeZT_bS8_No-cEftRjqPPptLx+zV2+_DqV=KYZYRcw@mail.gmail.com>
 <CA+OCxoyLMvyRpPSMztrUf0st7yGvyeYquOmyFabQzg6Czieh=Q@mail.gmail.com>
 <CAKKotZRW4WF2gsaPu-cRZJmrAia0GiDTOhwDKQdUpBC5VRoVjQ@mail.gmail.com>
 <CA+OCxoyF37xc+S4=r37KRAEh+zUfN4-WBSSv1YSe1VZpMmNfkg@mail.gmail.com>
 <CAKKotZSz3kgLYGNyu_BGORF+J=F2qmLa-2z9Rzq1HgSjXjTyZg@mail.gmail.com>
 <CA+OCxoymEzDsLaABZixOjQ37jJdP1J7+xJ6By_oJHi=2bSRoRg@mail.gmail.com>
 <CAKKotZSrWzCVBbuywF8VFGMtMK-VdT=fyo_3gY97OnoO7hZspw@mail.gmail.com>
 <CA+OCxowWbW6sYELhWiCGW3znKE6Fk19Hwuns8BzZHd94iqABnA@mail.gmail.com>
 <CA+OCxozg9xXuCy86gaxvnfX646XpeP5c9g0ycW1oE-k-jg22cA@mail.gmail.com>
 <CAKKotZRA0sLv6Aiua2h8FXpyqrjXg=Wt6WipVK4O_xCpdnfvgA@mail.gmail.com>
 <CA+OCxoyCRkmA29pCZh9PhG0ZSLgRYwX+5yyqHCYTxZjkDVHcHw@mail.gmail.com>
 <CACCA4P2BOCiNDisEfTi_aSTSugUFTjZea-YZ-AWZNSBN8Lj63w@mail.gmail.com>
From: Dave Page <dpage@pgadmin.org>
Date: Fri, 21 Oct 2016 12:33:40 +0100
Message-ID: 
 <CA+OCxoyjy2T0iCKR_ACkp7sZyJ0+R-0UT75zkyAwahn36R5fpQ@mail.gmail.com>
Subject: Re: PATCH: To fix the issue in Debugger module (pgAdmin4)
To: Neel Patel <neel.patel@enterprisedb.com>
Cc: Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com>,
	pgadmin-hackers <pgadmin-hackers@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgadmin-hackers-owner@postgresql.org

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 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?

>>
>>
>> - 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
>> <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 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@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 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


-- 
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers