postgres-data-handler migrations timeout - public_key_first_transaction

[StarGeezerPhil]

In re:

postgres-data-handler/migrations/post_sync_migrations/migration_helpers.go

Line 85 in cbef29c

ctx, cancel := context.WithTimeout(context.Background(), 90*time.Minute)

This hardcoded time-out fails with the construction of the public_key_first_transaction table due to the sheer volume of transactions to be processed this late in the sync process.

The specific migration in question:

postgres-data-handler/migrations/post_sync_migrations/20230713000002_create_statistic_views.go

Line 15 in cbef29c

err := RunMigrationWithRetries(db, `

			CREATE TABLE public_key_first_transaction (
				public_key VARCHAR PRIMARY KEY ,
				timestamp TIMESTAMP,
				height BIGINT
			);
			
			CREATE INDEX idx_public_key_first_transaction_timestamp
			ON public_key_first_transaction (timestamp desc);
			
			CREATE INDEX idx_public_key_first_transaction_height
			ON public_key_first_transaction (height desc);
			
			INSERT INTO public_key_first_transaction (public_key, timestamp, height)
			select apk.public_key, min(b.timestamp), min(b.height) FROM affected_public_key apk
			JOIN transaction t ON apk.transaction_hash = t.transaction_hash
			JOIN block b ON t.block_hash = b.block_hash
			group by apk.public_key;

Suggested fixes:

⌛ Environment Variable - (workaround) expose an environment variable that operators can set for any such failures during the sync / migrations process.

🔥 Re-order migration process - (full fix) prepare these table relationships and indices BEFORE mass sync occurs. This would remove this huge overhead so late in the process and would mean that postgres itself would build this table automatically as the sync proceeds.

[StarGeezerPhil]

Att: @superzordon @diamondhands0 @lazynina

[StarGeezerPhil]

To update this, running that specific migration manually:

4 hours 24 minutes to complete.