Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bX75j-0002zk-I5 for pgadmin-hackers@arkaria.postgresql.org; Tue, 09 Aug 2016 13:29:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bX75i-0002lD-KE for pgadmin-hackers@arkaria.postgresql.org; Tue, 09 Aug 2016 13:29:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bX75V-0002X9-Dp for pgadmin-hackers@postgresql.org; Tue, 09 Aug 2016 13:28:57 +0000 Received: from mail-it0-x234.google.com ([2607:f8b0:4001:c0b::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bX75R-0005h8-PS for pgadmin-hackers@postgresql.org; Tue, 09 Aug 2016 13:28:56 +0000 Received: by mail-it0-x234.google.com with SMTP id f6so13934194ith.0 for ; Tue, 09 Aug 2016 06:28:53 -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=4X/x8yH4qem5UHiYbTTI+6sJZGOHE6+LAlvS3rsCwR0=; b=LojiIOTEjjnuAoCL3lD/iomUdvOegj1BJgEitMZrlXZhgxt8wkOriXFhNhCitMKYO2 BQrzK3qRU5vL73m3A1ITdzfM3LtOOXkqjmr74X0s0VOVBLVo5wnex7QopTZjyjwueDZ1 InOA5TQ/tDiI3kTaWo8zwuEvlZrjXsiGZZTK/iqBa4mwqRjj+osVFWGpi0YsGCJqxY8L ic5yj27ornylWxfu/NGthUsqDPbqu0i6xi52r+utYcyrAw9oA001aYg6XQeN3pc+BPPX C0ZsZVGHsj9XbM4kT8bhUiw5rFV0LahBFWbDMBWh2nxiJC4pderxJASl7g49U+0qCRDR jZvQ== 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=4X/x8yH4qem5UHiYbTTI+6sJZGOHE6+LAlvS3rsCwR0=; b=J3gCCv2aVvYHvgCiBCXqr4luxm9KYIXLIk5Zz8Dhpz6IuuJmNh8gNFP3ZOgrn7wVBL Pg9KSxzqBgQKUsNpSXp+r2hdsF7HT1A9aVAEEh5qQMbmLemN+lajvL7JJd5DVf+w9Tfo L892OwpqqnIno5Za/ZbyMFiLJV0TkIQe4Wk59and9LBB7lT1ggI8A1gmUTrZG0FW5JB7 8RwnwcpkxKVCKw4jpCc03PT/OWecfqGT4dNimXge7oTpCaeNaFjVqWiXaEAICVK9zuPe 9+v3+fYQJDMhhvTb6Nzi2TdxsvwoweB8blgewLu5TE+QtsdjaWTwhKagyA4sCNKPH25M MDmA== X-Gm-Message-State: AEkooutm9KqIPHgjxj2u4hnZsVk2LLUgmT9mUbcKo3EXT2LgAeBA3sig86q5U4o1QzJvYBloAuoceBR6s+qWkw== X-Received: by 10.36.117.79 with SMTP id y76mr23435467itc.35.1470749331800; Tue, 09 Aug 2016 06:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.208.97 with HTTP; Tue, 9 Aug 2016 06:28:50 -0700 (PDT) In-Reply-To: References: From: Dave Page Date: Tue, 9 Aug 2016 14:28:50 +0100 Message-ID: Subject: Re: PATCH: To fix the issue where message panel was showing incomplete info (pgAdmin4) To: Ashesh Vashi Cc: Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary=001a114a90ce79db980539a3830d 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 --001a114a90ce79db980539a3830d Content-Type: text/plain; charset=UTF-8 On Tue, Aug 9, 2016 at 2:21 PM, Ashesh Vashi wrote: > On Tue, Aug 9, 2016 at 6:47 PM, Dave Page wrote: > >> >> >> On Tue, Aug 9, 2016 at 2:07 PM, Ashesh Vashi < >> ashesh.vashi@enterprisedb.com> wrote: >> >>> On Tue, Aug 9, 2016 at 6:34 PM, Dave Page wrote: >>> >>>> >>>> >>>> On Tue, Aug 9, 2016 at 2:01 PM, Ashesh Vashi < >>>> ashesh.vashi@enterprisedb.com> wrote: >>>> >>>>> On Tue, Aug 9, 2016 at 6:28 PM, Dave Page wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Tue, Aug 9, 2016 at 8:07 AM, Murtuza Zabuawala >>>>>> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > PFA patch to fix the issue where message panel was showing >>>>>> incomplete info. >>>>>> > We may still miss some messages from Psycopg2 driver due to limited >>>>>> size of >>>>>> > notices queue. >>>>>> > (RM#1523) >>>>>> >>>>>> A few thoughts on this (mostly based on my discussions with Ashesh): >>>>>> >>>>>> 1) You seem to have removed the poll delay. I assume that is to try to >>>>>> avoid missing messages? Can we re-introduce the delay (to avoid >>>>>> excessive network requests), but collect messages while we're waiting? >>>>>> >>>>> Using thread? >>>>> Start a thread during the timeout? >>>>> >>>> >>>> Not necessarily. If we want a 2 second polling delay, we could just >>>> sleep for 0.5 secs, collect messages, sleep for 0.5 sec, collect messages, >>>> return to client. >>>> >>> That's a very huge delay in practical. >>> We were hardly waiting for during poll (that was in milliseconds), but - >>> still we were loosing a lot of the messages. (a lot more from the current >>> implementation). >>> >> >> What was the original delay? Now there appears to be none at all. >> > That was 10 milliseconds > Hmm, Ok - for some reason I thought it was much longer. Ignore that point then :-) -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --001a114a90ce79db980539a3830d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 9, 2016 at 2:21 PM, Ashesh Vashi <ashesh.vashi= @enterprisedb.com> wrote:
<= div dir=3D"ltr">

On Tue, Aug 9, 2016 at 6:47 PM, Dave Page <d= page@pgadmin.org> wrote:



On= Tue, Aug 9, 2016 at 2:07 PM, Ashesh Vashi <ashesh.vashi@enter= prisedb.com> wrote:

On Tue, Aug 9, 2016 at 6:34 PM, Dave Page <dpage@pgadmin.org> wrote:


<= br>
On Tue, Aug 9, 2016 at 2:01 PM, Ashesh = Vashi <ashesh.vashi@enterprisedb.com> wrote= :

On Tue, Aug 9, 2016 at 6:28 PM, D= ave Page <dpage@pgadmin.org> wrote:

Hi

On Tue, Aug 9, 2016 at 8:07 AM, Murtuza Zabuawala
<murtuza.zabuawala@enterprisedb.com> wrote:
> Hi,
>
> PFA patch to fix the issue where message panel was showing incomplete = info.
> We may still miss some messages from Psycopg2 driver due to limited si= ze of
> notices queue.
> (RM#1523)

A few thoughts on this (mostly based on my discussions with Ashesh):=

1) You seem to have removed the poll delay. I assume that is to try to
avoid missing messages? Can we re-introduce the delay (to avoid
excessive network requests), but collect messages while we're waiting?<= br>
Using thread?
Start a thread during t= he timeout?

= Not necessarily. If we want a 2 second polling delay, we could just sleep f= or 0.5 secs, collect messages, sleep for 0.5 sec, collect messages, <rep= eat...> return to client.
That's a very huge delay in practical.
We were hardly waiti= ng for during poll (that was in milliseconds), but - still we were loosing = a lot of the messages. (a lot more from the current implementation).
<= /div>

What was the origi= nal delay? Now there appears to be none at all.
That was 10 milliseconds

Hmm, Ok - for some reason I thought it was much = longer. Ignore that point then :-)
=C2=A0
--
Dave Page
B= log: http://pgsna= ke.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com=
The Enterprise PostgreSQL Company
--001a114a90ce79db980539a3830d--