Re: pg_listener table errors with slony

On Wed, Jun 1, 2011 at 7:39 PM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> On Wed, 2011-06-01 at 16:13 +0000, Dave Page wrote:
>> On Wed, Jun 1, 2011 at 4:11 PM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>> > On Wed, 2011-06-01 at 09:58 +0000, Dave Page wrote:
>> >> Hi Guillaume
>> >>
>> >> On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge
>> >> <guillaume(at)lelarge(dot)info> wrote:
>> >> > Le 19/01/2011 22:33, Dave Page a écrit :
>> >> >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge
>> >> >> <guillaume(at)lelarge(dot)info> wrote:
>> >> >>> We had 1.2 support. To have 2.0, we would have to get rid of the
>> >> >>> sl_trigger checks. Or was it dropped along the way of 2.0?
>> >> >>
>> >> >> No idea - I just recall Sachin working on compatibility, and that was
>> >> >> one of/the patch he came of with.
>> >> >>
>> >> >
>> >> > Yeah, you're right. I now see the commit. Which means we have two bugs
>> >> > on 2.0 support.
>> >>
>> >> What happened with this in the end? I've just run into the pg_listener
>> >> bug again. I see from the thread you said you were going to work on
>> >> it, but then we got side-tracked into a discussion on whether we
>> >> should have slony support at all.
>> >>
>> >
>> > I still have it on my todo list.
>>
>> OK, well I'm looking at the moment to see if we can do something with
>> sl_nodelock as Steve suggested, in combination with pg_stat_activity.
>>
>> What was the other bug? I'm not sure I understand what that issue is.
>>
>
> The issue I wanted to work on is the pg_listener one. pg_listener is
> available till 9.0. With the rework on the LISTEN/NOTIFY implementation
> in 9.0, all calls to pg_listener fail because pg_listener isn't
> available anymore. So we need to find another way to get the listener
> PID.

Yeah, that was the original issue reported, but you mentioned there
was another one?

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

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