On Wed, Jun 1, 2011 at 3:02 PM, Steve Singer <ssinger@ca.afilias.info> wrote:
> 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
Thanks - I've committed changes that use pg_stat_activity and
sl_nodelock to try to figure out what's currently going on.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
