> 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.