IntersectMBO / cardano-node-tests

System and end-to-end (E2E) tests for cardano-node.
https://tests.cardano.intersectmbo.org/
Apache License 2.0
55 stars 29 forks source link

`only_utxo` preset - discrepancies between the docs and the code #2494

Closed ArturWieczorek closed 4 months ago

ArturWieczorek commented 4 months ago

Docs: https://github.com/IntersectMBO/cardano-db-sync/pull/1644/files#diff-c2f1f64eeb5238c809d70b333d9987646e84982e0b133ffa4e0ca1ff86c78448

This description is a bit confusing: It presents Only UTxO preset config as equivalent to multi_asset: false and then later mentions : "When syncing is completed, it loads the whole UTxO set from the ledger to the tx_out and ma_tx_out tables. "

Only UTxO This is equivalent to setting: "tx_cbor": "disable", "tx_out": { "value": "bootstrap" }, "ledger": "ignore", "shelley": { "enable": false }, "metadata": { "enable": "false" }, "multi_asset": { "enable": "false" }, "plutus": { "enable": false }, "governance": "disable", "offchain_pool_data": "disable" "pool_stat": "disable"

Initially populates only a few tables, like block and tx. It maintains a ledger state but doesn't use any of its data. When syncing is completed, it loads the whole UTxO set from the ledger to the tx_out and ma_tx_out tables. After that db-sync can be restarted with ledger set to "disable" to continue syncing without maintaining the ledger

And here is the state after sync:

sancho_new_test_config_only_utxo=# select * from ma_tx_out;
 id | quantity | tx_out_id | ident 
----+----------+-----------+-------
(0 rows)

sancho_new_test_config_only_utxo=# select * from ma_tx_mint;
 id | quantity | tx_id | ident 
----+----------+-------+-------
(0 rows)

sancho_new_test_config_only_utxo=# select * from tx_in;
 id | tx_in_id | tx_out_id | tx_out_index | redeemer_id 
----+----------+-----------+--------------+-------------
(0 rows)

sancho_new_test_config_only_utxo=# select count(*) from tx_out;
 count 
-------
 71771
(1 row)

So my question is - should ma_tx_out be dropped from description in sentence:

When syncing is completed, it loads the whole UTxO set from the ledger to the tx_out and ma_tx_out tables.

or not. Which behaviour is correct, the one described in current docs or code ?

Additional Information:

0) cardano-db-sync built from here: https://github.com/IntersectMBO/cardano-db-sync/pull/1644 and run with node 9.0.0 rev: 2820a63dc934c6d5b5f450b6c2543b81c6476696

1) Config used:

...
  "RequiresNetworkMagic": "RequiresMagic",

  "insert_options": {
     "preset": "only_utxo"
  },
  "defaultBackends": [
    "KatipBK"
  ],
...

2) cardano-db-sync was fully synced - sanchonet:

[db-sync-node:Info:77] [2024-07-26 08:36:41.60 UTC] Starting epoch 406
[db-sync-node:Info:77] [2024-07-26 08:36:41.60 UTC] Insert Conway Block: epoch 406, slot 35078476, block 1752535, hash a1b60c760dcf2697da28e998c70da02ee37e58cf588682cef8255740a3ce217e
[db-sync-node:Info:77] [2024-07-26 08:36:42.67 UTC] Deleted 0 tx_out
[db-sync-node:Info:77] [2024-07-26 08:36:43.51 UTC] Insert Conway Block: epoch 406, slot 35129574, block 1755000, hash 2149680f367b415e6515609fa3be47d8625c45b1df78614b58ba12da5cf7245f
[db-sync-node:Info:77] [2024-07-26 08:36:44.77 UTC] Persistant SQL Statement Cache size is 37
[db-sync-node:Info:77] [2024-07-26 08:36:44.77 UTC] 
Cache Statistics:
  Stake Addresses: cache sizes: 0 and 0, hits: 0, misses: 0
  Pools: cache size: 0, hit rate: 0%, hits: 0, misses: 1756649
  Datums: cache capacity: 250000, cache size: 0, hits: 0, misses: 0
  Multi Assets: cache capacity: 250000, cache size: 0, hits: 0, misses: 0
  Previous Block: hit rate: 49%, hits: 1756648, misses: 1756649
  TxId: cache size: 11710, cache capacity: 300000, hits: 0, misses: 0
[db-sync-node:Info:77] [2024-07-26 08:36:44.77 UTC] Starting epoch 407
[db-sync-node:Info:77] [2024-07-26 08:36:44.78 UTC] Insert Conway Block: epoch 407, slot 35164816, block 1756649, hash e6e40b4667faac5f97986704e8cb98089b050d494accc327d564270b1c74c8ee
[db-sync-node:Info:77] [2024-07-26 08:36:45.76 UTC] Starting UTxO bootstrap migration
[db-sync-node:Info:77] [2024-07-26 08:36:45.76 UTC] Inserting 71825 tx_out as pages of 100000
[db-sync-node:Info:77] [2024-07-26 08:36:45.76 UTC] Bootstrap in progress 0.0%
[db-sync-node:Info:77] [2024-07-26 08:36:49.71 UTC] UTxO bootstrap migration done
[db-sync-node:Info:77] [2024-07-26 08:36:49.71 UTC] The table epoch_stake was given a new unique constraint called unique_epoch_stake
[db-sync-node:Info:77] [2024-07-26 08:36:49.71 UTC] The table reward was given a new unique constraint called unique_reward
[db-sync-node:Info:77] [2024-07-26 08:36:49.72 UTC] Running database migrations in mode Indexes
[db-sync-node:Info:77] [2024-07-26 08:36:49.72 UTC] Found maintenance_work_mem=1GB, max_parallel_maintenance_workers=6
[db-sync-node:Warning:77] [2024-07-26 08:36:49.72 UTC] Creating Indexes. This may require an extended period of time to perform. Setting a higher maintenance_work_mem from Postgres usually speeds up this process. These indexes are not used by db-sync but are meant for clients. If you want to skip some of these indexes, you can stop db-sync, delete or modify any migration-4-* files in the schema directory and restart it.
[db-sync-node:Info:77] [2024-07-26 08:36:51.47 UTC] Indexes were created
[db-sync-node:Info:77] [2024-07-26 08:36:51.53 UTC] Insert Conway Block: epoch 407, slot 35193900, block 1758029, hash f42f5e7a083e82d61866f859782a44e6bfbb745275c51b8b33826e021407ccc9
[db-sync-node:Info:77] [2024-07-26 08:36:51.53 UTC] Insert Conway Block: epoch 407, slot 35193914, block 1758030, hash 9ad010b02000a71974f55adf79f3d5280afaffe7052045978bd879720255b1f2
[db-sync-node:Info:77] [2024-07-26 08:36:51.54 UTC] Insert Conway Block: epoch 407, slot 35193922, block 1758031, hash e7da1ae7e851a0fd2b7670a12c0eb42454237a854f3c2338eae7fbb920fe4b41
[db-sync-node:Info:77] [2024-07-26 08:36:51.54 UTC] Insert Conway Block: epoch 407, slot 35193963, block 1758032, hash 524373dde357252b80f98bda27ff8b487cd3de4ae64cbb18d70bbc6ba1850531
[db-sync-node:Info:77] [2024-07-26 08:36:51.54 UTC] Insert Conway Block: epoch 407, slot 35194001, block 1758033, hash 73da988fc70d8290bac38a7f83654934554fd17cc4747ea9bd938beb130ad90e
ArturWieczorek commented 4 months ago

Wrong repository.