Christopher,
Many thanks for this.  It appears to be corruption of the sl_log_1
index.  I added instrumentation into slony to show the queries executed
and ddl generated.  This showed duplicates being returned from sl_log_1.
Running the same query using psql showed no duplicates.  Adding "set
enable_seqscan = off; set enable_indexscan = on;" to the transaction,
showed the duplicates.  The index rebuild has got us moving again.

On Fri, 2006-06-23 at 02:13 +0000, Christopher Browne wrote:
> It could be worth reindexing sl_log_1 on the source node; that would
> regrettably block new (replicable) activity there, but would *hopefully*
> be quick; if that helped, that would indicate a corruption of the index
> on sl_log_1.  (You have tried to rule that out; it's quite possible that
> you have done so successfully...)  If sl_log_1 isn't too big, yet, that
                   ^^^^^^^^^^^^
Apparantly not :-)

Two feature requests arise from all of this:
- could we have an extra level of debugging that shows the sql being
issued?
- could the sync group size be reset to 1 after an error is encountered?
Perpetually retrying a group of 30 when the 20th sync contains an error
prevents progress on the first 19, and makes tracking down the error
data slower and harder than it might be.

Thanks again.
__
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060623/b861290d/attachment.bin