Message-ID: <gh-pgjdbc-pgjdbc-3483-c2597852523@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Fri, 17 Jan 2025 09:54:54 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3483: Support adaptive fetching without enforcing memory limits, and/or have a separate buffer size for it
In-Reply-To: <gh-pgjdbc-pgjdbc-3483@github.com>
References: <gh-pgjdbc-pgjdbc-3483@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: vlsi
X-GitHub-Comment-Id: 2597852523
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 3483
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3483#issuecomment-2597852523
Content-Type: text/plain; charset=utf-8

> but then the application starts filling out a fat JSON blob in every newer row

Even a single json can exceed the limits, so I am not sure we can do much from the client side to make it 100% safe.
I would be nice if the backend could support "fetch at most N rows and stop the fetch after M bytes sent".

I wonder if it can come as a connection-level property like `suspend_portals_after_sending=50MiB`, so it would automatically suspend portals as it produces the given number of bytes.

Then it would reduce the chances for "out of memory" in case the application uses row-limited fetch. For instance, currently we issue `fetch N` request, and we don't care how many rows it produces. We wait for `PortalSuspended` vs `CommandComplete` messages to tell if there's anything left.