On E, 2005-11-07 at 17:52 -0500, Jan Wieck wrote:
> On 11/7/2005 3:40 PM, Christopher Browne wrote:
> > Hannu Krosing <hannu at skype.net> writes:
> >> On E, 2005-11-07 at 07:29 -0500, Jan Wieck wrote:
> >>> On 11/7/2005 4:11 AM, Hannu Krosing wrote:
> >>> > On L, 2005-11-05 at 12:48 +0000, Dave Page wrote:
> >>> >> It doesn't :-(
> >>> > 
> >>> > What are the issues ?
> >>> > 
> >>> > Is anybody working on it ?
> >>> 
> >>> The issue is a change in a backend internal interface function to 
> >>> LISTEN/NOTIFY, that we use to cleanup stale pg_listener entries after a 
> >>> postmaster crash. I do have a plan and am working on it. Fixes will be 
> >>> applied to HEAD and 1_1_STABLE soon.
> >>
> >> Would it be worthwhile to change postgresql (too late for 8.1 but
> >> maybe for 8.2 if LISTEN/NOTIFY is not completely rewritten there) by
> >> adding "TRUNACTE PG_LISTENER;" to postgresql's startup code and also
> >> in cleanup after kill -9 initiated restarts ?
> > 
> > That seems overly aggressive, and I'm not sure it would work anyways.
> > 
> > The upcoming problem is that pg_listener won't be tracking PIDs the
> > same way, and we use the PIDs at present to detect whether a
> > particular node is "claimed" by a slon process yet.
> 
> This isn't entirely accurate.
> 
> The current problem is just that the call to Async_Unlisten() lost its 
> pid argument, so one backend cannot remove stale entries from another 
> one any more via this call.

If the problem is just removing stale entries, then I would not mind if
was just done on a "best effort" basis, and failure would be not fatal.
Btw, this did not work reliably even in 1.0.5 or 1.1.0 on either pg 7.4
or 8.0.

It often get errors like "tuple modified in this transaction" and I
still have to clean pg_listener manually. This happened when there were
duplicate entries in pg_listener. 

-- 
Hannu Krosing <hannu at skype.net>