Error: insert or update on table "pool_offline_fetch_error" #806
Comments
|
I am now running the I am expecting this to fail. I will then apply commit 4013035 which I am hoping fixes this. |
I am going to bed. |
|
My @dmitrystas I assume your instance completed syncing after that rollback. |
|
There is a race condition that can result in this error, between the OfflineFetch thread and the ChainSync thread. It can happen if these events happen in this order:
There is nothing to prevent this from happening right now. It results in a restart and a rollback to the latest ledger state. However the error is not fatal, db-sync can sync further from that point. @dmitrystas do you have the logs before the crash or do you remember if there was a rollback? Solutions could be adding some delay to the OfflineFetch, to avoid inserting very recent pmr_id which may get rolled back, or some communication between the threads. |
|
@kderme Yes, that makes sense. Nice analysis. I think communicating between the threads is a little too complicated. A better solution might be to only query the Another, even better solution is to catch that error and drop it (with a log message). This would avoid a the large rollback @dmitrystas saw, and the offline metadata would simply be fetched at a later time. |
If a rollback occurs after the PoolMetadataRef is fetched, the insertion of the result can fail. In this insert fail case, we simply log and drop the exception. Closes: #806
If a rollback occurs after the PoolMetadataRef is fetched, the insertion of the result can fail. In this insert fail case, we simply log and drop the exception. Closes: #806
erikd
changed the title
If a rollback removes the PoolMetadataRef from the database after it is queried, the insertion of the result can fail. In this insert fail case, we simply log and drop the exception. Closes: #806
@kderme as far as I remember there was a rollback, so you're probably right |
|
@MarcelKlammer Your issue is completely unrelated to this and therefore has been moved to #809 . |
This avoids the race condition described in the ticket #806 below. It does so by ensuring the required foreign keys exist before the insert. If the required foreign keys do not exist the data is just dropped and will be refetched later. Cherry pick of d658f38 from master. Closes: #806 Closes: #823 Closes: #831
Mainnet, epoch 289
cardano-db-sync 11.0.0 - linux-x86_64 - ghc-8.10
git revision 07ee3b0
Important to note that although PostgreSQL reports this as a fatal error,
db-syncdoes not consider it fatal, but rolls back to the start of the epoch and tries again. The second time around this will not fail because the rolled backPoolMetadataRefrow no longer exists and a new correctPoolMetadataRefrow exists in its place.from logs
The text was updated successfully, but these errors were encountered: