On 9/28/2012 2:40 PM, Brian Fehrle wrote:
> I'm going to go ahead and delete the offending row in sl_event for the
> node that doesn't exist. This is a production environment so I need to
> get up and running again.

Deleting a SYNC event of a non-origin node can never have any negative 
side effects. They are noise that keeps sl_status looking good, but 
that's really all they do.

SYNC events from a set origin are a little different. A SYNC immediately 
before an EXECUTE_SCRIPT event prior to 2.2 may be important. Other than 
that, they don't matter that much either.

When a node has fallen behind, it deliberately skips a number of SYNC 
events, a feature we call sync-grouping, to catch up in larger leaps. 
There is no difference at all between slon grouping SYNC events and some 
SYNC event rows missing in sl_event. Absolutely zero difference.

The difference for the SYNC event from a set origin in front of an 
EXECUTE_SCRIPT is because that DDL may add a column to a table. That 
SYNC event was supposed to make sure that the column exists on a 
subscriber when the first data containing that column appeared in 
sl_log_N. That all changed in 2.2 as well, where DDL from script 
execution now travels within sl_log_N too, so as of 2.2 you can simply 
delete all SYNC events from sl_event if you feel like. Slon will 
generate another SYNC soon and the processing of that will just leap the 
receivers to that state.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin