Ah, thanks. I just started looking through the 1.1 code, and noticed
that the handling in this area had changed. Looks like I have an excuse
to upgrade now! Wahoo...

-DAP 

> -----Original Message-----
> From: cbbrowne at ca.afilias.info [mailto:cbbrowne at ca.afilias.info] 
> Sent: Wednesday, October 05, 2005 8:15 AM
> To: David Parker
> Cc: slony1-general at gborg.postgresql.org
> Subject: Re: [Slony1-general] error in cleanup_thread
> 
> > Hi. We recently started testing with slony 1.0.5, and we are seeing 
> > our slon exit every once in a while with the error in the log:
> >
> > FATAL cleanupThread: "vacuum analyze "_tzreplic".sl_event; vacuum 
> > analyze "_tzreplic".sl_confirm; vacuum analyze "_tzreplic".sl_set 
> > sync; vacuum analyze "_tzreplic".sl_log_1; vacuum analyze 
> > "_tzreplic".sl_log_2;vacuum analyze "_tzreplic".sl_seqlog;vacuum 
> > analyze p g_catalog.pg_listener;" - ERROR: tuple 
> concurrently updated
> > DEBUG1 main: scheduler mainloop returned
> > DEBUG1 syncThread: thread done
> > DEBUG1 localListenThread: thread done
> > DEBUG1 main: done
> >
> > So, pg_listener was added to list of tables to be vacuumed 
> in 1.0.5, 
> > which seems to be causing this problem (the database log 
> indicates the 
> > error is coming from the vacuum on this table).
> >
> > The connection being used in cleanup_thread does not appear 
> to be in a 
> > serialized transaction so I assume that is coming from 
> vacuum itself?
> > Our application uses listen/notify in different places, so it's 
> > entirely possible that pg_listener could get updated during 
> > cleanup_thread processing.
> >
> > I understand why pg_listener was added to the vacuum list, but I'm 
> > wondering if the response to an error from this command should be a 
> > process exit? Perhaps the error handling could be more granular to 
> > take into account the concurrent update case?
> 
> The behaviour of this was substantially improved in version 
> 1.1, with two relevant changes:
> 
> a) Each VACUUM is submitted separately (so that if one fails, 
> the others are, at least in principle, able to succeed) 
> rather than as one statement
> 
> b) Failures are treated as matters to warn about, not to 
> cause the slon to fall over.
> 
>