Re: BUG #3504: Some listening sessions never return from writing, problems ensue - Mailing list pgsql-bugs

From Peter Koczan
Subject Re: BUG #3504: Some listening sessions never return from writing, problems ensue
Date
Msg-id 4544e0330708061247g35d6aa47p68d4aa67ca38bf78@mail.gmail.com
Whole thread Raw
In response to Re: BUG #3504: Some listening sessions never return from writing, problems ensue  (Peter Koczan <pjkoczan@gmail.com>)
List pgsql-bugs
Here's what the primary maintainer of the app had to say about how notifies
get read.

This is in update_reqs in Gtkreq, which gets called by a Gtk timer
every second.  Then, as long as there are notifies, it will
continue to read from the req log.

There's a timer for every instance of the main window, so it looks
like if you have more than one main window open, update_reqs would
be called more often.  That might have to be changed.

So, it looks like the app polls for async notifies every second. Hopefully
you can glean some insight from that.

Peter

On 8/3/07, Peter Koczan <pjkoczan@gmail.com> wrote:
>
> I think the code is somehow interrupt based, but I don't know. I've
> asked the primary maintainer of the program to look into this with me.
> We should have more insight by early next week.
>
> Peter
>
> Tom Lane wrote:
> > "Peter Koczan" <pjkoczan@gmail.com> writes:
> >
> >> This app uses Perl/DBD::Pg, and the code is basically:
> >>
> >
> >
> >> while ($dbh->func('pg_notifies')) {
> >>   # do stuff
> >> }
> >>
> >
> > If I'm not mistaken, that loop would process all the currently available
> > notify messages and then fall out.  So the real question is what's
> > around this --- what conditions will make the program come back to this
> > loop periodically?  Or not do so?
> >
>

pgsql-bugs by date:

Previous
From: "Mouhamadou Dia"
Date:
Subject: RE : RE : BUG #3519: Postgres takes the wrong query plan resulting in performance issues
Next
From: "Peter Koczan"
Date:
Subject: Re: BUG #3504: Some listening sessions never return from writing, problems ensue