Known issues that dont warrant actual issues

[snowkidind]

Sometimes a note about the operation is necessary but there really isnt any plan to address the behavior. Digest below addresses those issues:

Double Sync
there is an issue where, when erigon is behind and catching up, it sends a flood of new blocks. this shouldn't have any negative effects on the rippers' sync, but it does lead to some strange log output when both systems are trying to catch up. Therefore, at the moment, I am recommending that if your node has to catch up and the ripper is behind, best practice to pause txTheRipper sync in order to restore normalcy to the overall state of the node.

[snowkidind]

During the batch conversion process, several child processes are spawned to manage the bubble sorting necessary to optimize and reduce the size of the database. Should some type of crash occur that causes one of these child processes to terminate, the entire system is shut down. Upon restart all temp files are deleted and it starts from the last sync point.

It's probably this if you see an error such as:

2023-11-13 12:57:57 ERROR: spawn file does not exist 1

[snowkidind]

During one of these occasions above, should there be a fatal bug, check with htop that there arent remnants of the SQL queries eating up CPU space. Basically its best to restart postgres e.g. systemctl restart postgresql Of course, make sure you run down any critical processes connected to postgres should you do this.

[snowkidind]

if you are running the software already and are having errors, this fix will allow you to use the same datastore without resyncing everything:

there was an issue where the application data and topic tables were storing an index height in an integer row, and it exceeded the max db value of 2,147,483,647 causing the program to stop synchronizing. Those were updated with:

ALTER TABLE application_data ALTER COLUMN value_int TYPE BIGINT;
ALTER TABLE topic ALTER COLUMN parent TYPE BIGINT;

WARNING: The second operation takes a long time to update 2.2 billion rows and creates an exclusive lock on the entire table. Do it in a tmux or overnight.

If you are currently experiencing this problem, turn it all off, update the database using this line, pull the code and restart.