This could be very nice to ensure no or limited downtime during migration application.
Of course, right now we can't interrupt a query because postgresql-simple is not interruption safe, so we would have to wait [TIMELIMIT + duration of some statement until its completion]. Maybe it's best to wait until we have a better library (hpgsql, hopefully) to do this.
Another alternative is to set transaction_timeout as a connection time setting. We could document the details might change in the future (e.g. we if add anticipated locking as a feature, it's conceivable we might not want this timeout to apply to waiting for locks).
We also have to be careful not to let COMMIT itself be interrupted. In fact, we could make COMMIT uninterruptible right now, and emit a warning "Ignoring SIGXXX because COMMIT is running, so this would be very risky. Press Ctrl+C or send signal again to interrupt anyway".
This could be very nice to ensure no or limited downtime during migration application.
Of course, right now we can't interrupt a query because postgresql-simple is not interruption safe, so we would have to wait [TIMELIMIT + duration of some statement until its completion]. Maybe it's best to wait until we have a better library (hpgsql, hopefully) to do this.
Another alternative is to set transaction_timeout as a connection time setting. We could document the details might change in the future (e.g. we if add anticipated locking as a feature, it's conceivable we might not want this timeout to apply to waiting for locks).
We also have to be careful not to let
COMMITitself be interrupted. In fact, we could makeCOMMITuninterruptible right now, and emit a warning "Ignoring SIGXXX because COMMIT is running, so this would be very risky. Press Ctrl+C or send signal again to interrupt anyway".