pgjdbc LargeObject API no longer hangs in transaction pooling
Before 3.10.7, pg_doorman did not forward PostgreSQL Fastpath
FunctionCall (F) messages in transaction pooling. pgjdbc uses these
messages for LargeObjectManager operations such as lo_creat, lo_write,
and lo_read. Hibernate applications that reach the same pgjdbc API could
block while waiting for FunctionCallResponse and ReadyForQuery.
3.10.7 forwards FunctionCall, sends FunctionCallResponse (V) back to the
client, and keeps the transaction-pool backend checked out until PostgreSQL
sends ReadyForQuery. Calls inside BEGIN/COMMIT stay on the same backend
until the transaction ends. Autocommit calls release the backend after
ReadyForQuery reports idle.
Large lo_read responses are streamed
Large FunctionCallResponse frames now use the same large-message streaming
code as DataRow and CopyData. pg_doorman forwards a large fastpath
lo_read response without first storing the whole frame in memory.
The release includes BDD tests for raw fastpath calls in explicit transactions
and autocommit mode, plus a pgjdbc/Hikari large object round trip with a
multi-MiB value.
Upgrade notes
No config changes are required.
Applications that previously timed out on pgjdbc large object calls may now
send that traffic through pg_doorman. Size transaction pools for concurrent
large object reads and writes, and keep application reads chunked.
Fastpath and large object guide:
https://ozontech.github.io/pg_doorman/operations/fastpath-large-objects.html
Full changelog:
https://ozontech.github.io/pg_doorman/changelog.html
pgjdbc LargeObject API больше не зависает в transaction pooling
До 3.10.7 pg_doorman не проксировал PostgreSQL Fastpath FunctionCall (F) в
transaction pooling. pgjdbc использует эти сообщения для операций
LargeObjectManager: lo_creat, lo_write, lo_read и других.
Hibernate-приложения, которые доходят до того же API pgjdbc, могли зависнуть в ожидании
FunctionCallResponse и ReadyForQuery.
В 3.10.7 pg_doorman проксирует FunctionCall, возвращает клиенту
FunctionCallResponse (V) и держит backend в transaction pool до
ReadyForQuery от PostgreSQL. Вызовы внутри BEGIN/COMMIT остаются на том
же backend до конца транзакции. В autocommit backend освобождается после
ReadyForQuery со статусом idle.
Большие lo_read идут через streaming
Крупные FunctionCallResponse теперь используют тот же large-message
streaming, что и DataRow с CopyData. Большой ответ fastpath lo_read
больше не лежит целиком в памяти pg_doorman перед отправкой клиенту.
В релиз добавлены BDD-тесты для raw fastpath вызовов в явной транзакции и в
autocommit, а также pgjdbc/Hikari large object round trip с multi-MiB
значением.
Замечания по апгрейду
Менять конфиг не нужно.
Приложения, которые раньше получали timeout на pgjdbc large object вызовах,
теперь могут пропускать этот трафик через pg_doorman. Размер transaction pool
нужно считать с учётом одновременных large object read/write. Large object
лучше читать порциями на стороне приложения.
Гайд по Fastpath и large objects:
https://ozontech.github.io/pg_doorman/operations/fastpath-large-objects.html
Полная история изменений:
https://ozontech.github.io/pg_doorman/changelog.html