fix: Add a configurable lock_timeout (default 5s) to add_partitions

[codybswaney]

Summary

add_partitions runs its CREATE ... PARTITION OF statements inside one transaction, each of which briefly needs a lock on the partitioned parent. With no lock_timeout set, a contended run waits indefinitely on that lock and can queue writers behind it.

This sets SET LOCAL lock_timeout (default 5s) on the add_partitions transaction so those statements back off instead of blocking. On timeout the statement errors, the transaction rolls back, and the caller sees a failed extension it can retry — rather than a run that hangs on a lock.

The timeout is configurable, matching the existing swap/unswap convention:

• --lock-timeout (default 5s) on the add_partitions and maintain commands.
• lockTimeout on AddPartitionsOptions and MaintainOptions; maintain() forwards it to addPartitions.

Test plan

• add_partitions defaults to a 5s lock_timeout and honors a custom override (asserted via SHOW lock_timeout).
• maintain forwards a custom lockTimeout through to the add_partitions transaction.
• Full suite green (394 tests); tsc and Prettier clean.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR adds a configurable lock timeout for partition creation. The main changes are:

• Adds lockTimeout to AddPartitionsOptions and MaintainOptions.
• Sets SET LOCAL lock_timeout inside the addPartitions transaction, defaulting to 5s.
• Adds --lock-timeout to the add_partitions and maintain commands.
• Forwards the maintain timeout setting into each addPartitions call.
• Adds tests for the default timeout, custom overrides, and maintain forwarding.

Confidence Score: 5/5

The change is focused and covered by targeted tests for default behavior, custom overrides, and option forwarding.

The implementation follows the existing timeout configuration pattern and the added tests exercise the new transaction-local lock timeout behavior.

T-Rex Logs

What T-Rex did

• The base add-partitions lock timeout run established the initial state with HELP_STATUS=0 OK and HELP_HAS_LOCK_TIMEOUT=false, led by CUSTOM_RUN_STATUS=1 ERROR, and test exit code 1, while the environment probe found no Postgres runtime blocking the requested SHOW lock_timeout.
• The after run showed the head operation forwarding lockTimeout to addPartitions, with SHOW lock_timeout observed and the test exited with code 0.
• Before: the maintain API could not forward lockTimeout, SHOW lock_timeout remained 0, and the maintain CLI rejected --lock-timeout, exiting 1.
• After: the maintain CLI accepted --lock-timeout 10s and forwarded it to addPartitions; SHOW lock_timeout reported 10s and the operation exited with code 0, extending the table.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix: Add a configurable lock_timeout (de..." | Re-trigger Greptile}