ponder_sync.rpcRequestResults table exceeds postgres index limits

[gte620v]

My ponder instance crashed with the following error:

WARN  sync       Failed 'insertRpcRequestResult' database method after '10' attempts

error: index row size 2880 exceeds btree version 4 maximum 2704 for index "rpcRequestResultPrimaryKey"

Looking at the database logs, I see this further error detail:

{
  "file": null,
  "metadata": [],
  "parsed": [
    {
      "application_name": "Supavisor",
      "backend_type": "client backend",
      "command_tag": "INSERT",
      "context": null,
      "database_name": "postgres",
      "detail": "Index row references tuple (99,9) in relation \"rpcRequestResults\".",
      "error_severity": "ERROR",
      "hint": "Values larger than 1/3 of a buffer page cannot be indexed.\nConsider a function index of an MD5 hash of the value, or use full text indexing.",
      "internal_query": null,
      "internal_query_pos": null,
      "leader_pid": null,
      "location": null,
      "process_id": 393078,
      "query": "insert into \"ponder_sync\".\"rpcRequestResults\" (\"request\", \"blockNumber\", \"chainId\", \"result\") values ($1, $2, $3, $4) on conflict (\"request\", \"chainId\", \"blockNumber\") do update set \"result\" = $5",
      "query_id": -2291873031451942400,
      "query_pos": null,
      "session_id": "66e9c189.5ff76",
      "session_line_num": 4,
      "sql_state_code": "54000",
      "transaction_id": 1270124,
      "virtual_transaction_id": "24/185014"
    }
  ],
  "parsed_from": null,
  "project": null,
  "source_type": null
}

Any suggestions on a fix?

[gte620v]

Looks like it is caused by some big periodic multicalls I was making. Refactoring those seems to have fixed the issue.

[typedarray]

Thanks for opening. Yeah, splitting into several multicalls is probably the best workaround. Will keep this in mind though - at one point we considered "unbundling" multicalls for storage in that cache table, but decided against it.

How many calls and what kind of input data were you doing here, and how many after the fix? We could consider a quick validation that would have nudged you to split it up earlier on / during development. Might prevent this happening to someone else in prod.

[gte620v]

Is an embarrassing amount... had 300 calls in a single multicall. The calls all had one argument. The db didnt complain for days, so it took a while to hit whatever limit pg has.

[gte620v]

might be useful to have an option to tell the context read to not write the rpc calldata to the db.

my use case was to check that the ponder state of my contracts (based on events-driven typescript implementation of the contract code) matches the state of the on-chain contracts (collected through rpc calls). this was running about once per day using the block-number driven ponder cron mechanism.

[jwahdatehagh]

getting this on & off from client.getEnsName calls (which i think are automatically batched)