On Oct 4, 2005, at 9:25 AM, David Parker wrote:

> 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?
>
> - DAP
> ======================================================
> David Parker    Tazz Networks

In ordinary postgres operation, the "tuple concurrently updated"  
error is a result of two backends trying to ANALYZE the same table  
simultaneously.

I agree that it seems odd that the cleanupThread would die as a  
result of this error since the side effect is supposedly just the  
failure of the VACUUM itself to complete.

In the meantime, are you, by chance, running pg_autovacuum or  
something else that would lead to attempts to ANALYZE in addition to  
the cleanup thread? I was under the impression that the cleanup  
thread was supposed to alleviate the need for pg_autovacuum.

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i?

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5150
615-469-5151 (fax)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20051005/5b38efe5/attachment-0001.html