Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bxXqw-0006wT-3N for pgadmin-hackers@arkaria.postgresql.org; Fri, 21 Oct 2016 11:19:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bxXqv-0003lD-LA for pgadmin-hackers@arkaria.postgresql.org; Fri, 21 Oct 2016 11:19:09 +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 1bxXqi-0003Wq-Aw for pgadmin-hackers@postgresql.org; Fri, 21 Oct 2016 11:18:56 +0000 Received: from mail-it0-x22a.google.com ([2607:f8b0:4001:c0b::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bxXqf-0004t0-5s for pgadmin-hackers@postgresql.org; Fri, 21 Oct 2016 11:18:54 +0000 Received: by mail-it0-x22a.google.com with SMTP id k64so48053834itb.0 for ; Fri, 21 Oct 2016 04:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QufiHGkgV8GUmuV7gBiD7eNf42K9er2g3IFEi8ZxsyM=; b=zeqnIIiUEQlKeIRFiDTgMQcZaKbNd3I+ZLTHH2ViAEBiSnH7d3DmX7gPtd59XJ8xZV o1XmjwzeHEdjaJnUm8D5XYlhxk7stu7RcyIIgQM6XgYtvi0Jk+gX8FCzhJ9GTaMKYePp 68ec6SVBNOar0W7DO/lYES0oafBVgGqGFA2rXPhWtkPb4sUN8+yIukiCaSIe9v1lfnco xQRfWWk67XXmoTfp+hSuKIYzK7Dg94aDap049wpq8SiQQxwt8vG38fjVj9qwOr6Wd+KC Nvp2UHRG0znwI93kY/a7fDIlzMsqI9JV0521BG0RmuAMB76yWdsFw05FRYxUpcPuLbb4 gNUQ== 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=QufiHGkgV8GUmuV7gBiD7eNf42K9er2g3IFEi8ZxsyM=; b=mIT186Yn8O0s9VOsmyTFsC6HfkYinZRBpLOsVe+40A8CIIojryQkuHCyuyJ0w/x/u9 AWQigtHvwKfQQj864RTPprQLFwW7CpD9HlP9Y4PKcRhEbYSogoUXogBGq3jHkstt4PaB Dg6X8oChSwOW8XVwhw7epVWvljzeMCyywmETQCZh7bXdwCYaHFePh8vjSl/qHNMmi8VI clvweNraiVHQLcQHGCXApkqXrzIxuZzV4ofi06iUREaz5qLAWjXUgh4NFQ235XR+U/UG ugKQ+0dmIg1rKeucA3kUeeQFUOHF4kn9KjHIq3Fvx9W50AxU/UzEyGnF4AgPAzOfMQkI 8ueQ== X-Gm-Message-State: ABUngveDI50/Eu2hZgurIYdaKNyg+iARCM4l6xDxHMd/UszcDcMIAo8lHlX7cylqs3mENeXattrw8C781KH+/w== X-Received: by 10.36.6.130 with SMTP id 124mr320428itv.94.1477048731558; Fri, 21 Oct 2016 04:18:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.82.130 with HTTP; Fri, 21 Oct 2016 04:18:50 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Fri, 21 Oct 2016 12:18:50 +0100 Message-ID: Subject: Re: PATCH: To fix the issue in Debugger module (pgAdmin4) To: Murtuza Zabuawala Cc: pgadmin-hackers Content-Type: text/plain; charset=UTF-8 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 Hi There are still issues I'm afraid: - When execution stops, we seem to keep polling for more results indefinitely. - 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. 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