Re: pg_listener in 9.0
От | Steve Singer |
---|---|
Тема | Re: pg_listener in 9.0 |
Дата | |
Msg-id | 4DE6466B.6060309@ca.afilias.info обсуждение исходный текст |
Ответ на | Re: pg_listener in 9.0 (Christopher Browne <cbbrowne@gmail.com>) |
Ответы |
Re: pg_listener in 9.0
|
Список | pgsql-hackers |
On 11-06-01 09:30 AM, Christopher Browne wrote: > On Wed, Jun 1, 2011 at 8:29 AM, Dave Page<dpage@pgadmin.org> wrote: >> On Wed, Jun 1, 2011 at 12:27 PM, Andrew Dunstan<andrew@dunslane.net> wrote: >>> The whole point of the revamp was that pg_listener was a major performance >>> bottleneck and needed to go, and without it being gone we would not have got >>> notification payloads. >> Yeah, I know why it was replaced. That doesn't mean we cannot provide >> an alternative interface to the same info though (other things might >> of course). >> >>> I suspect you're pretty much out of luck. >> Not me - our users. > Note that in Slony 2.1, there's a table called sl_components, which is > used to capture the state of the various database connections, > checking in as the various threads do their various actions. > > Also, slon and slonik try to report their respective application, so > it can be reported on pg_stat_activity. Slony 2.1 also sets application_name. If this were a big deal for pgAdmin we could consider backporting the application_name change to 2.0.x for users running against 9.0. Slony also has a table called sl_nodelock that each slon process writes adds a row for on startup. This includes the backend pid() for one of the connections. Slony 1.2, 2.0 and 2.1 all use sl_nodelock
В списке pgsql-hackers по дате отправления: