Re: [Slony1-general] Slony1_funcs broken with 8.1

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: [Slony1-general] Slony1_funcs broken with 8.1
Date: 2005-10-23 09:57:08
Message-ID: 435B5E74.8070703@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>> So postmaster doesn't clean up pg_listener,
>
>
> It never has. If you're complaining about this patch
> http://archives.postgresql.org/pgsql-committers/2005-10/msg00073.php
> you ought to say so, rather than expecting us to guess it from an
> out-of-context quote from another mailing list.

Not complaining, just RFC.
But I wonder why postmaster doesn't truncate pg_listener at restart,
since PIDs can't be valid any more (truncating would reduce bloating
too). A redesign based on shmem or so wouldn't keep the data either.

>
> As near as I can tell, the technique Jan describes is an abuse of
> pg_listener, and I won't feel any great sympathy when it does break
> completely, which it will do before long when pg_listener goes away
> in the planned rewrite of LISTEN/NOTIFY.

Well slony uses LISTEN for its main purpose too. I'd guess there's
always a demand to find out which backend is listening, so a pg_listener
(probably a view wrapping a function) will be necessary.

AFAICS a backend that notices loss of client connection will usually
clean up its listener entries, so apparently slony doesn't need to take
care of this, at least for 8.1 (with the postmaster crash exception).

Regards,
Andreas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-10-23 10:00:56 Re: Question about Ctrl-C and less
Previous Message Gregory Maxwell 2005-10-23 07:11:06 On externals sorts and other IO bottlenecks in postgresql.