Nomadic Labs indexer bootstrap fails with statement timeout

Question

I restored the database of the Nomadic Labs indexer using a snapshot called "v10.2.0.20220817.sql", then updated the schema to v10.2.1 with make db-schema-all-default | psql -p 5433 --username=user --dbname=db and then tried to bootstrap the indexer with the Docker image using:

docker run -it --rm --net=host registry.gitlab.com/nomadic-labs/tezos-indexer/tezos-indexer:v10.2.1 --verbose --db=postgresql://user:user@localhost:5433/db --tezos-url=[local node url]

The error I get, after some apparently successful insertions in the database is the following:

> event=insert block_level=2630354 block=BLn8VrkdhDxc type=contract_balance address=tz1cpaeGrCgrWcYm5kAWbestAV8Pr22aARod balance=356.294474
Database error: Request to <postgresql://user:_@localhost:5433/db> failed: ERROR:  canceling statement due to statement timeout
CONTEXT:  PL/pgSQL function b.get_for_copy(bigint,integer,bigint,bigint) line 15 at RETURN QUERY
SQL statement "INSERT INTO C.bigmap
 (id, "key", key_hash, "key_type", "value", value_type, block_level, sender_id, receiver_id, i,                    operation_id, implicit_operations_results_id, kind, annots, strings, uri, contracts, metadata, operation_hash_id) --
SELECT
 yid, r."key", r.key_hash, r."key_type", r."value", r.value_type, xblock_level, xsender, xreceiver,
 xi, opaid, iorid, coalesce((select -1 where kind < 1), 3), r.annots, r.strings, r.uri, r.contracts, r.metadata, ophid
FROM B.get_for_copy (xid, xblock_level, ophid, xi) r
ON CONFLICT DO NOTHING"
PL/pgSQL function b.copy(bigint,bigint,integer,bigint,bigint,bigint,bigint,integer,bigint) line 5 at SQL statement
 Query: "select B.copy($1,$2,$3,$4,$5,$6,$7,$8,$9)".

I actually had this issue even before restoring the snapshot, and trying to start afresh does not fix it. I checked that the statement timeout is not set by default:

db=> show statement_timeout;
 statement_timeout 
-------------------
 0
(1 row)

db=> SELECT current_setting('statement_timeout');
 current_setting 
-----------------
 0
(1 row)

Could it be that the indexer is setting its own timeout for its session? If so, how can I change it?

(Note that user and db are just placeholders in the fragments above.)

Answer 1

There's a default value for the DB timeout, as you may read from the README or from --help:

       --timeout=VAL (absent=60s)
           Specify DB query timeout. If no unit is given, the integer is
           considered a number of milliseconds. 0 means no timeout. Examples:
           10s, 1234ms, 42m. Cf. Postgres' documentation for more
           information. This can be very useful if your instance gets stuck
           sometimes and you'd like it to crash so you can automatically
           restart it. (Since v9.7.9)

If your hardware is not fast enough, it'll be indeed necessary to increase the 60s timeout value.

If ever you're not interested in big maps anyways, let me know: it's not very complicated to deactivate recording big maps in the DB.