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.pa...@enterprisedb.com> wrote: > Hi, > > > On Fri, Oct 21, 2016 at 5:03 PM, Dave Page <dp...@pgadmin.org> wrote: > >> Hi >> >> On Fri, Oct 21, 2016 at 12:32 PM, Neel Patel >> <neel.pa...@enterprisedb.com> wrote: >> > Hi, >> > >> > >> > On Fri, Oct 21, 2016 at 4:48 PM, Dave Page <dp...@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? >> > > 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.zabuaw...@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 <dp...@pgadmin.org> wrote: >> >> >> >> >> >> On Fri, Oct 7, 2016 at 12:53 PM, Dave Page <dp...@pgadmin.org> >> wrote: >> >> >> > On Fri, Oct 7, 2016 at 12:42 PM, Murtuza Zabuawala >> >> >> > <murtuza.zabuaw...@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 >> > >
RM_1227_v8.patch
Description: Binary data
-- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
