[Bug] graphman truncate doesn't remove 300 GB of the old blocks from db

Bug report

When using graphman chain truncate I still see over 2.5 million blocks in chain4.blocks table and 5.5 million in chain5.blocks inside postgres. They are taking around 300 GB of space. Why are they not removed? Can I remove them in any other way? I don't see a reason why they are kept there.

Relevant log output

graphDB=# SELECT
    table_schema || '.' || table_name AS "table_full_name",
    pg_size_pretty(pg_total_relation_size('"' || table_schema || '"."' || table_name || '"')) AS "size"
FROM
    information_schema.tables
WHERE
    table_schema NOT IN ('pg_catalog', 'information_schema')
ORDER BY
    pg_total_relation_size('"' || table_schema || '"."' || table_name || '"') DESC;
                 table_full_name                 |    size
-------------------------------------------------+------------
 chain4.blocks                                   | 167 GB
 chain5.blocks                                   | 146 GB


graphDB=# select count(*) from chain4.blocks;
  count
---------
 2627100

graphDB=# select count(*) from chain5.blocks;
  count
---------
 5482991

graphDB=# SELECT reltoastrelid::regclass AS toast_table_name,
       pg_size_pretty(pg_relation_size(reltoastrelid)) AS toast_table_size
FROM pg_class
WHERE relname = 'blocks';
     toast_table_name      | toast_table_size
---------------------------+------------------
 pg_toast.pg_toast_5695384 | 165 GB
 pg_toast.pg_toast_5695408 | 142 GB
 pg_toast.pg_toast_18030   | 105 MB
 pg_toast.pg_toast_18054   | 0 bytes
 pg_toast.pg_toast_2412454 | 5592 kB

IPFS hash

No response

Subgraph name or link to explorer

No response

Some information to help us out

• Tick this box if this bug is caused by a regression found in the latest release.
• Tick this box if this bug is specific to the hosted service.
• I have searched the issue tracker to make sure this issue is not a duplicate.

OS information

Linux

The report centers on graphman chain truncate and the PostgreSQL chain4.blocks and chain5.blocks tables. Start by reproducing the truncation and checking the reported row counts, table sizes, and TOAST sizes before and after it runs. Done means the command's behavior is explained and the old blocks are removed or a documented cleanup path is identified.