Jonathan Chappelow

That sucks. I don't know what to recommend. I assume you're not out of disk space? What did you mean by "fast forward"? Like this? https://github.com/decred/dcrdata/blob/fab8a7e7bde6f4382ae9613db706a41788e7a0f3/db/dcrpg/chkdcrpg/main.go#L197-L221 BTW, those blks/sec are...

`2022-01-19 20:59:08.169 [INF] PSQL: Current best block (dcrd): 341542` Do you know why this is not more like 870897? Is dcrd syncing at the same time?

OK, don't try to do dcrdata sync until dcrd has finished it's sync/IBD (initial block download). Does it still panic even if dcrd is idle and all synchronized with the...

OK I'm going to run a fresh sync on both mainnet and testnet. The fast forward loop is not a solution though. We need to get to the root cause.

And how is disk utilization then? The production testnet machine uses up almost all of that on just the postgresql DB: ``` postgres=# SELECT datname, pg_size_pretty(pg_database_size(datname)) db_size FROM pg_database ORDER...

I think you're out of disk space... When you hit the error, check `df -h` and report back. Also check dcrd logs and `journalctl -e`

> That's a lot of space Yeah, 120 GB is a surprising amount. On mainnet: ``` postgres=# SELECT datname, pg_size_pretty(pg_database_size(datname)) db_size FROM pg_database ORDER BY db_size; datname | db_size -----------------+---------...

Scraping the limits of usable space there. You should check the postgresql logs as well as dcrd logs and journalctl. I'd be very surprised if at least one of those...

fresh mainnet sync stage 1 passed: ``` 2022-02-06 17:44:07.553 [INF] PSQL: Processing blocks 631001 to 631317... 2022-02-06 17:44:15.453 [INF] PSQL: ( 40 blk/s, 725 tx/s, 4134 vin/sec, 4953 vout/s) 2022-02-06...

OK, we can do this. It will take some exporting of raw block data from various nodes however. Then development of some simple tooling to make the import/export process streamlined...