Remove the restriction that a batch that returns generated keys is executed internally as individual queries.
With this change PgJDBC now executes batches that return generated keys in internal sub-batches separated by periodic Sync, flush, and input consume pauses, just, like it does for batches that don't return keys.
This is safe (or almost as safe as it ever was given github #194) because we force a Describe, then estimate the result row size and adjust the batch size accordingly.
This approach does increase the deadlock risk if a batch executes statements where each statement returns many generated keys (e.g. a big multi-entry
Fixes github #195.
The tests for batches didn't cover series of DML statements well.
Per GitHub issue #194 and the comments above MAX_BUFFERED_QUERIES, we're using a pretty rough heuristic for receive buffer management. This approach can't account for the data in prepared queries that return generated keys, it assumes a flat 250 bytes per query response. Change that, the buffer in bytes, up to an estimated MAX_BUFFERED_RECV_BYTES (still 64k, same as before) with an estimated NODATA_QUERY_RESPONSE_SIZE_BYTES or 250 bytes per query. Behaviour is not changed, we're just counting bytes instead of queries. This means that it's now possible to adjust the baseline NODATA_QUERY_RESPONSE_SIZE_BYTES for the size of any returned columns in a query with a RETURNING clause in a subsequent patch.
With this change, PgJDBC calculates the estimated return size for the result row, assuming that each batch item returns one row for getGeneratedKeys() use. Instead of forcing batching off and sending individual queries, it then queues enough binds and executes to fit safely within the receive buffer and server's send buffer before sending a sync and reading the result buffer. Batching is still forced off when the result set size cannot be estimated (e.g. due to unbounded 'text' columns, use of arrays in the result set, etc). This is a minimal workaround for github issue #195, though it doesn't prevent deadlocks that can already occur due to #194.