Re: BUG #3504: Some listening sessions never return from writing, problems ensue
От | Peter Koczan |
---|---|
Тема | Re: BUG #3504: Some listening sessions never return from writing, problems ensue |
Дата | |
Msg-id | 4544e0330708061247g35d6aa47p68d4aa67ca38bf78@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #3504: Some listening sessions never return from writing, problems ensue (Peter Koczan <pjkoczan@gmail.com>) |
Список | 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 по дате отправления: