Re: pg_listener in 9.0

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_listener in 9.0
Date: 2011-06-01 12:04:26
Message-ID: BANLkTinDSa2MCZx8fVXyh4YqSPomPq5U+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 1, 2011 at 11:27 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 01.06.2011 13:09, Dave Page wrote:
>>
>> The pg_listener table was removed in 9.0 in the revamp of
>> LISTEN/NOTIFY. In pgAdmin we used to perform a number of selects from
>> the table to get information about Slony clusters - for example, the
>> PID of the slon process or to check if a process is listening for a
>> specific notification. This allows the app to indicate to the user if
>> there is something wrong with their replication cluster.
>>
>> I can't find any way to get that information now - any ideas?
>
> Hmm, my first thought was that we should add a view to display that
> information, but that's not possible, because we don't have that information
> in shared memory. The information on what channels are being listened on is
> now backend-local.
>
> Does the slon process set application_name? You could query pg_stat_activity
> with that.

I don't think so (though I might be wrong), but even if it did, it
wouldn't tell us what cluster it was running against (we figure that
out by looking at what it's listening for). We also do the same check
in reverse, to check there is something listening for specific
notifications.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2011-06-01 12:18:22 Re: Cube Index Size
Previous Message Robert Haas 2011-06-01 11:40:27 Re: [PERFORM] Hash Anti Join performance degradation