Statement time limit

A project database enforces a 10-second limit per statement. Beyond that the statement is cancelled with:

[57014] canceling statement due to statement timeout

Why it exists

Your project's database runs in the same process as the worker, on a single lane. One long statement makes every other request to that project wait behind it. The limit caps that wait at 10 seconds.

show statement_timeout says 0

This limit is not PostgreSQL's statement_timeout setting; it is a ceiling the runtime holds separately. So SHOW statement_timeout answers 0, and SET statement_timeout cannot raise it. Lowering works — a shorter statement_timeout on the session fires first.

Both use the same SQLSTATE 57014, so they are not distinguishable by code. If it cut off near 10 seconds, it was this ceiling.

When you hit it

Split the statement. Batch large UPDATEs by key range and run them several times; chunk bulk INSERTs to about 1,000 rows each inside one session transaction.

// Recomputing best_rank for 12,000 places — one statement would exceed 10 s
for (let offset = 0; ; offset += 2000) {
  const ids = await env.db.exec("select id from places order by id limit 2000 offset $1", [offset]);
  if (ids.length === 0) break;
  await env.db.exec(
    `update places p set best_rank = b.min_rank
       from (select place_id, min(rank) as min_rank from rankings
              where place_id = any($1) group by place_id) b
      where b.place_id = p.id`,
    [ids.map((r) => r.id)],
  );
}

A migration that passed on an empty table can hit the limit on the same statement once data is present. Correlated-subquery UPDATEs are the usual case — aggregate once and join, and it usually fits.

Values