Skip to content

Bump org.postgresql:postgresql from 42.4.4 to 42.7.11 in /contrib/storage-jdbc#3048

Merged
cgivre merged 2 commits into
masterfrom
dependabot/maven/contrib/storage-jdbc/org.postgresql-postgresql-42.7.11
Jun 23, 2026
Merged

Bump org.postgresql:postgresql from 42.4.4 to 42.7.11 in /contrib/storage-jdbc#3048
cgivre merged 2 commits into
masterfrom
dependabot/maven/contrib/storage-jdbc/org.postgresql-postgresql-42.7.11

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github May 15, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Bumps org.postgresql:postgresql from 42.4.4 to 42.7.11.

Release notes

Sourced from org.postgresql:postgresql's releases.

v42.7.11

Security

  • fix: Limit SCRAM PBKDF2 iterations accepted from the server. pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins. See the Security Advisory for more detail. The following CVE-2026-42198 has been issued.

Changes

🐛 Bug Fixes

  • fix: ensure extended protocol messages end with Sync message @​vlsi (#3728)
  • fix: enable cursor-based fetching in extended protocol when transaction started via SQL command @​vlsi (#3996)
  • fix: retry with SSL on IOException when sslMode=ALLOW @​vlsi (#3973)
  • fix: allow fallback to non-SSL connection when sslMode=prefer and sslResponseTimeout kicks in @​vlsi (#3968)
  • fix: catch SecurityException from setContextClassLoader on ForkJoinPool workers @​vlsi (#3962)
  • fix: use compareTo for LogSequenceNumber comparison @​vlsi (#3961)
  • fix: release COPY lock on IOException to prevent connection hang (#3957) @​vlsi (#3960)

🧰 Maintenance

⬆️ Dependencies

... (truncated)

Changelog

Sourced from org.postgresql:postgresql's changelog.

[42.7.11] (2026-04-28)

Security

  • fix: Limit SCRAM PBKDF2 iterations accepted from the server. pgjdbc was vulnerable to a client-side denial of service in SCRAM-SHA-256 authentication, where a malicious or compromised PostgreSQL server could specify an extremely large PBKDF2 iteration count, causing the client to consume unbounded CPU and potentially exhaust connection pools. The fix introduces a new scramMaxIterations connection property (defaulting to 100,000) to cap iteration counts before computation begins. See the Security Advisory for more detail. The following CVE-2026-42198 has been issued.

Added

Changed

Fixed

[42.7.10] (2026-02-11)

Changed

Fixed

Reverted

[42.7.9] (2026-01-14)

Added

... (truncated)

Commits
  • 78e261f fix: Add sources and javadocs to shaded published lib generation
  • 1e09fa0 update Changelog and website for release of 42.7.11 (#4042)
  • d479fa5 Fix scram fix location in changelog and update published artifact developer l...
  • b04fc46 docs: Add scram max iters fix to changelog
  • cf54822 test: Disable scram test on older version without scram_iterations GUC
  • 7dbcc79 test: Add SCRAM max iteration tests
  • c9d41d1 fix: Limit SCRAM PBKDF2 iterations accepted from the server
  • a340cb2 style: replace @​exception with @​throws in getBoolean javadoc
  • 77837f8 fix(deps): update dependency org.openrewrite.rewrite:org.openrewrite.rewrite....
  • 23af03b chore(deps): update actions/checkout action to v6
  • Additional commits viewable in compare view

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

@dependabot dependabot Bot added dependencies java Pull requests that update java code labels May 15, 2026
@cgivre

cgivre commented May 17, 2026

Copy link
Copy Markdown
Contributor

@dependabot rebase

@dependabot
Bump org.postgresql:postgresql in /contrib/storage-jdbc
d26b96e 
Bumps [org.postgresql:postgresql](https://github.com/pgjdbc/pgjdbc) from 42.4.4 to 42.7.11.
- [Release notes](https://github.com/pgjdbc/pgjdbc/releases)
- [Changelog](https://github.com/pgjdbc/pgjdbc/blob/master/CHANGELOG.md)
- [Commits](pgjdbc/pgjdbc@REL42.4.4...REL42.7.11)

---
updated-dependencies:
- dependency-name: org.postgresql:postgresql
  dependency-version: 42.7.11
  dependency-type: direct:development
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot force-pushed the dependabot/maven/contrib/storage-jdbc/org.postgresql-postgresql-42.7.11 branch from caf5255 to d26b96e Compare May 17, 2026 06:26
@cgivre

cgivre commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

I pushed a follow-up commit (Keep JDBC schemas at top level with postgresql 42.7+) so this bump can actually pass CI.

Why the bump alone failed: with 42.4.4 the Postgres tests pass, but bumping to 42.7.11 broke every Postgres storage test with VALIDATION ERROR: Schema [pg.public] is not valid. H2/MySQL tests were unaffected.

Root cause: a DatabaseMetaData behavior change in pgjdbc 42.7.x. I reproduced it against a real postgres:12.8-alpine3.14 container:

Call 42.4.4 42.7.11
getCatalogs() drill_postgres_test drill_postgres_test, postgres, template1
getSchemas() → TABLE_CATALOG null drill_postgres_test

JdbcCatalogSchema.addSchemas() uses the TABLE_CATALOG value to decide nesting: when it's non-null and matches a known catalog, the schema is attached under that catalog. So public moved from pg.public to pg.<database>.public — which fails every query (and the default schema is no longer resolved). This isn't just a test issue: it would silently change the schema paths that existing Drill+Postgres users query.

Fix: capture the connection's own database via Connection.getCatalog() and treat a schema whose TABLE_CATALOG equals it the same as a null catalog, keeping it at the top level (pg.public). The guard is a no-op for drivers that report a null or non-matching catalog (MySQL, H2, etc.), so existing behavior is preserved. Verified the placement is pg.public with both 42.7.11 and 42.4.4. mvn checkstyle:check on the module is clean.

(Heads-up: since this PR now carries a manual commit, Dependabot will stop rebasing it.)

@cgivre
Keep JDBC schemas at top level with postgresql 42.7+
898a519 
The PostgreSQL JDBC driver 42.7+ reports the connection's own database as the
TABLE_CATALOG for DatabaseMetaData.getSchemas(), whereas 42.4.x reported null.
JdbcCatalogSchema used that catalog value to nest schemas under their catalog,
so "pg.public" silently became "pg.<database>.public". This broke every Postgres
storage test ("Schema [pg.public] is not valid") and would have changed the
schema paths existing Drill users query.

When the driver reports catalogs other than the connection's own (as servers
like PostgreSQL do, listing sibling databases a single connection cannot query
across), register the connection's own catalog's schemas at the plugin top level
rather than nested under the catalog. This restores the pre-42.7 paths without
any dialect-specific code. Single-catalog sources such as H2 keep their existing
catalog nesting, so "h2.tmp.drill_h2_test" is unaffected.
@cgivre cgivre force-pushed the dependabot/maven/contrib/storage-jdbc/org.postgresql-postgresql-42.7.11 branch from 5552acb to 898a519 Compare June 23, 2026 14:28
@cgivre

cgivre commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Revised the follow-up commit to avoid dialect-specific code and to fix an H2 regression my first attempt introduced.

What was wrong with the first attempt: flattening any schema whose TABLE_CATALOG equals the connection's own catalog also flattened H2, which legitimately wants its catalog as a navigable level (h2.tmp.drill_h2_test). H2 and Postgres report structurally identical metadata here, so that signal can't distinguish them.

General rule used instead (no per-dialect branching): a JDBC connection is bound to a single catalog. If getCatalogs() reports catalogs other than the connection's own (servers like PostgreSQL list sibling databases — postgres, template1 — that a single connection can't query across), the catalog level isn't navigable, so the connection's own catalog's schemas are registered at the plugin top level (pg.public). If the only catalog reported is the connection's own (embedded/file sources like H2), the existing catalog nesting is kept (h2.tmp.drill_h2_test). This is a no-op for pre-42.7 drivers, which already report null catalogs.

Verification (local):

  • Probe against a real postgres:12.8 container: schema placement is identical for 42.4.4 and 42.7.11 → pg.public, pg.information_schema, pg.pg_catalog all top-level (matches pre-bump behavior).
  • H2 suites run green: TestJdbcInsertWithH2 (4), TestJdbcWriterWithH2 (14), TestJdbcPluginWithH2IT (18) — including the USE h2; SHOW TABLES default-schema cases, which my first attempt broke.
  • MySQL/ClickHouse are untouched (MySQL returns no rows from getSchemas(); ClickHouse uses its own catalog schema).

mvn checkstyle:check on the module is clean. CI will exercise the Postgres + MySQL containers.

cgivre
cgivre approved these changes Jun 23, 2026
View reviewed changes

@cgivre cgivre left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM +1 (Pending CI)

@cgivre cgivre merged commit 9347026 into master Jun 23, 2026
11 of 12 checks passed
@cgivre cgivre deleted the dependabot/maven/contrib/storage-jdbc/org.postgresql-postgresql-42.7.11 branch June 23, 2026 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cgivre cgivre cgivre approved these changes

Assignees

No one assigned

Labels

dependencies java Pull requests that update java code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@cgivre