On Tue, Aug 9, 2016 at 2:21 PM, Ashesh Vashi <ashesh.va...@enterprisedb.com> wrote:
> On Tue, Aug 9, 2016 at 6:47 PM, Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Tue, Aug 9, 2016 at 2:07 PM, Ashesh Vashi < >> ashesh.va...@enterprisedb.com> wrote: >> >>> On Tue, Aug 9, 2016 at 6:34 PM, Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Tue, Aug 9, 2016 at 2:01 PM, Ashesh Vashi < >>>> ashesh.va...@enterprisedb.com> wrote: >>>> >>>>> On Tue, Aug 9, 2016 at 6:28 PM, Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Tue, Aug 9, 2016 at 8:07 AM, Murtuza Zabuawala >>>>>> <murtuza.zabuaw...@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 >>>>>> 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, >>>> <repeat...> 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
