Redshift Patch 203: sessions holding a partially-consumed result set terminated after exactly 300s, session_timeout reports 14400

After a cluster was patched to 1.0.377293 (Patch 203) last week, any session that leaves a partially-consumed result set open is terminated after almost exactly 300 seconds:

org.postgresql.util.PSQLException: FATAL: terminating connection due to session timeout

Steps to reproduce

Current Redshift JDBC driver (redshift-jdbc42):

1. Connect with enableFetchRingBuffer=false
2. setFetchSize(5000) on a query returning 20,000 rows
3. Fetch the first batch, then sleep 600 seconds
4. Attempt the next fetch

Result: terminated at 300s.

On the other hand, with the ring buffer left at its default, the same harness completes all four batches across three 600-second pauses (because the driver drains the result set up front and leaves nothing pending server-side).

But note that enableFetchRingBuffer=false with a fetch size is a documented configuration! AWS's fetch size guidance recommends it for legacy applications requiring traditional fetch behaviour.

This also reproduces with the community PostgreSQL JDBC driver, which is how we first hit it: that driver always fetches on demand, so it always leaves a suspended portal.

The same harness, same driver, same settings against a Patch 202 cluster does not reproduce this at all.

What we're seeing

STL_SESSIONS.timed_out = 1 ("connection timed out") occurs consistently since the patch and does not appear once in the retained session history from before it.

Terminated sessions always run slightly over 300 seconds, with the excess accounted for by work done before the stall. So the timer appears to run from the last fetch rather than from connect.

Yet every terminated session reports timeout_sec = 14400 — i.e. the documented 4-hour cluster default, which applies because no user-level session timeout is set.

A plain idle session with no pending results is unaffected on the same cluster, so this appears specific to suspended portals rather than idle sessions generally.

Questions

1. Is this an intended change in Patch 203? The release notes mention "Fixed an issue where queries could hang indefinitely during session suspension handling". Could this new behavior be related?
2. Is a 300-second limit on the gap between fetches documented anywhere? We can't find it.
3. Is it configurable by any means?