core: Postgres error halts / corrupts syncing from block 98475 related to DAO TransferRestrictionStatus
During Postgres sync with the last Postgres Dao updates got this error:
server.go:1147] Server._handleBlock: Received block ( 98475 / 98627 ) from Peer [ Remote Address: 34.123.41.111:17000 PeerID=32 ] E0126 08:54:21.794215 1 server.go:1141] Server._handleBlock: Encountered an error processing block <Header: < 98475, 00000000000058e8268e3ca270ab453fdd41382623c5ca30516d6ddf95b7b764, 1 >, Signer Key: BC1YLh768bVj2R3QpSiduxcvn7ipxF3L3XHsabZYtCGtsinUnNrZvNN>. Disconnecting from peer [ Remote Address: 34.123.41.111:17000 PeerID=32 ]: Error while processing block: : ProcessBlock: Problem upserting block and transactions: ERROR #23502 null value in column "transfer_restriction_status" violates not-null constraint
Seem related to Dao coin insert/update at first glance. Related to
DAOCoinTransferRestrictionStatus TransferRestrictionStatus pg:"dao_coin_transfer_restriction_status"
When this block hits in the sync all blocks after get status 26 in pg_blocks.
Looking for a solution or fix.
So transfer_restriction_status SMALLINT NOT NULL seems to get a NULL value and rejects that.
type PGMetadataDAOCoin struct { tableName struct{}
pg:“pg_metadata_dao_coins”`
TransactionHash *BlockHash `pg:",pk,type:bytea"`
ProfilePublicKey []byte `pg:",type:bytea"`
OperationType DAOCoinOperationType `pg:",use_zero"`
CoinsToMintNanos string
CoinsToBurnNanos string
TransferRestrictionStatus `pg:",use_zero"`
}`
Might be related to pg:",use_zero"
for that enum type.
Would transfer_restriction_status SMALLINT NOT NULL with DEFAULT 0 added solve the issue? Took me 2 days to sync to get to that point. Any ideas are welcome.
This PR from @tijno brings us to block 98477 #201 But still seems something goes wrong with the status field
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (16 by maintainers)
Hey all, we’ve been investigating this but we’re making it our top priority to fix it today. Hoping we can have it fixed for you all shortly!
thx @diamondhands0 - ones you have a fix can you trigger backend image update - as that doesnt happen automatically to core changes i believe.
@diamondhands0 @maebeam Could we have feedback/resolution on this issue?
I’m stuck on 98476/7 - exactly the same as @tijno as reported in detail above.
I rebuilt node using the updated backend, clean postgres instance. Paused sync after the initial db setup and manually modified the erroneous column (pg_metadata_dao_coins.transfer_restriction_status, allowing null values). Then restarted sync and allowed to progress.
It progressed beyond the initial hold-up, but stuck same as @mvanhalen / @tijno.
Hey all, @lazynina fixed the issue. You can see the fix here. It turned out to be a pretty simple fix. Sorry for all the hassle:
To use the fix, you should just be able to restart your node with core version 2.0.4. I don’t think a resync is required.
Im doing full clean postgres sync with 2.0.3 right now - it will take a while before I get to 98k blocks but will report results.
Hmm… this is super weird. I’ve looked through the code several times now and can’t see how it could possibly break like this. Is it possible the migrations didn’t run on your Postgres db?
Hey @mvanhalen, can you please make sure you’re running release 2.02, which contains this commit?
If this doesn’t solve your issue let us know.