Avoid 'canceling statement due to conflict with recovery'

When graph-node uses a shard with read replicas, replication conflicts can lead to an error canceling statement due to conflict with recovery. With that error, it is generally ok to retry the query, possibly with some backoff. The retry logic should guard against queries though that take so long that they are virtually guaranteed to fail with that error. For example, a query that would take 2 minutes will almost certainly fail if the underlying deployment has a decent amount of updates.

One way to avoid this would be to retry the query not against the same replica, but against the main database, where this error cannot happen.

graph-node のシャードの読み取りレプリカにおけるクエリとリトライの経路を追跡し、その後、PostgreSQL のリカバリ競合エラーがどのように処理されているかを調査します。別のレプリカでリトライする方法と、クエリをメインデータベースにルーティングする方法を比較し、長時間実行されるクエリを考慮します。競合をリトライでき、レプリカに不適切なクエリを繰り返し送信しなくなれば完了です。