Message-ID: From: "davecramer (@davecramer)" To: "pgjdbc/pgjdbc" Date: Tue, 24 Feb 2026 16:44:59 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #3895: implement require_auth, this is pretty much how libpq does this. In-Reply-To: References: List-Id: X-GitHub-Author-Login: davecramer X-GitHub-Comment-Id: 3953384694 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 3895 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3895#issuecomment-3953384694 Content-Type: text/plain; charset=utf-8 > Why [3fab588](https://github.com/pgjdbc/pgjdbc/commit/3fab588d93ae4cfeb13f75ba08894b804b256d51) is the first bad commit > > The commit does two things: > > 1. Adds `autosave=always` to the CI test matrix > Before this commit, tests never ran with autosave=always. > The unlucky random combination assigned autosave=always to the PG 9.1 job. > 2. Changes shouldCreateAutomaticSavepoint() to create more savepoints > > The old code checked isTransactionActive() before checking AutoSave.NEVER, meaning it would bail out early in some cases. The new code reorders the checks and also expands isSpecialQuery() — but the net effect is that with autosave=always, every non-special statement now gets wrapped in SAVEPOINT / RELEASE SAVEPOINT. > > The combined effect > > DatabaseEncodingTest.encoding() does ~11,100 INSERTs in one transaction. With autosave=always, each INSERT creates a subtransaction. PG 9.1's default max_locks_per_transaction=64 gives only ~6,400 lock table slots — far fewer than the ~11,100 needed. > > Frankly, I think the test did the right thing: it identified a bug. > > Then we could have several workarounds: > > 1. Try if increase max_locks_per_transaction in the CI PostgreSQL 9.1 config helps (e.g., -c max_locks_per_transaction=256 in entrypoint.sh). > 2. Exclude autosave=always from PG 9.1 in the matrix — add a rule like: > `matrix.imply({pg_version: '9.1'}, {autosave: {value: 'never'}});` > 3. Add periodic commits in `DatabaseEncodingTest` to keep subtransaction count manageable > > I am leaning towards 1 or 2. easy enough to try 1 in the PR.