Richard

I am currently using 3.13.4. But my database goes back to 3.8 when it started. On Wed, 08 Mar 2023, 20:10 Jake Van Meter, jvanmeter@users.sourceforge.net wrote: It is fine to clean these up manually. Out of curiosity, what version of SymmetricDS are you running? Orphaned SYM_DATA and SYM_DATA_EVENT https://sourceforge.net/p/symmetricds/discussion/739236/thread/3024bb4612/?limit=25#e1ac Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/symmetricds/discussion/739236/...

Doesn't seem to be doing that. I take it then that stranded rows can be safely removed. I suppose I will do a manual clean-up.

I recently discovered that I have millions of orphaned rows in SYM_DATA and SYM_DATA_EVENT. select count(*) from SYM_DATA_EVENT e where not exists (select 1 from SYM_OUTGOING_BATCH b where b.batch_id = e.batch_id); I imagine that this has been caused by the way in which we have been deleting stale nodes. That is, by deleting the related records in SYM_OUTGOING_BATCH instead of setting the status to 'OK'. The question that I need answered is: Is it safe to manually delete the rows in SYM_DATA_EVENT...

Is it possible to exclude certain columns from an initial load? The excluded columns must still sync on regular database updates. The reason I need this is that I have a table that contains BLOB data, which causes a massive payload for the initial load.

Thanks Eric for the detailed and comprehensive explanation. Conflict resolution of USE_PK_DATA and NEWER_WINS works best for my scenario. Although, conflicts should be rare, so that is something that I will need to investigate.

My App Server and Postgres Database are both hosted in the same MS Azure region. I think connectivity and latency are excellent. Is there any way to see if any of the data in sym_data is orphaned and can be removed? I think I have some more insight into what caused this spike in CPU. I updated my software which caused hundreds of thousands, if not millions, of events that needed to be sync'd. After 2 days, when these were all distributed to the various client nodes, the symptoms have gone away. However,...

My App Server and Postgres Database are both hosted in the same MS Azure region. I think connectivity and latency are excellent. Is there any way to see if any of the data in sym_data is orphaned and can be removed? I think I have some more insight into what caused this spike in CPU. I updated my software which caused hundreds of thousands, if not millions, of events that needed to be sync'd. After 2 days, when these were all distributed to the various client nodes, the symptoms have gone away. However,...

Version is 3.12.9 on Postgres 11.