Postgres simple-query path materializes the entire result set in memory before sending (OOM on a large SELECT) #6679

Summary

The Postgres simple-query ('Q') path materializes the entire result set into a List<Result> in memory before writing the first DataRow, so a large SELECT over the simple protocol can OOM the server. The Bolt executor streams; the Postgres extended protocol is bounded by the portal max-rows; only the simple-query path is unbounded.

Where (HEAD 86a704526)

postgresw/src/main/java/com/arcadedb/postgres/PostgresNetworkExecutor.java:670 → final List<Result> cachedResultSet = browseAndCacheResultSet(resultSet, 0); (limit 0 = unlimited) then writeRowDescription(...) / writeDataRows(cachedResultSet, ...). All row objects are held simultaneously before the first byte is sent.

Repro

A plain SELECT over the simple query protocol (e.g. psql -c "SELECT FROM HugeType") against a large table → the whole result is buffered into an ArrayList server-side before streaming, risking OutOfMemoryError. The Bolt path (handlePull) streams row-by-row and does not exhibit this (verified).

Suggested fix

For the 'Q' path, iterate the ResultSet and write DataRows incrementally instead of pre-caching with limit 0; or cap with a configurable fetch bound.

Scope / confidence

High that everything is materialized (read at HEAD). Honest caveat: this is a long-standing, documented design (the browse-cache predates the #4197 audit and is deliberate for portal semantics), so it may be considered known/intended — reporting because it is a real "whole result materialized → OOM on a big simple-query SELECT" gap and the sibling transports avoid it.